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ABSTRACT 
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from didgital to software components", ACM 1998 
1-58113-008 Feb. 1998.* 



A system and method for testing the conformance of a 
universal serial bus (USB) system to a set of predefined USB 
Specifications. One embodiment of the system comprises a 
USB interpreter thai can be used to selectively examine 
device data, execute USB commands and exercise USB 
functions without having to create or compile a test program . 
The USB interpreter comprises a test application and a test 
application driver. The test application driver interfaces with 
the USB system software. The USB system software may 
include a USB driver, a host controller driver and other host 
software. The USB driver interfaces with the test application 
through the test application driver. The host controller driver 
interfaces with the host controller and thereby interfaces the 
software on the host system with the USB interconnect and 
USB devices. In one embodiment, the USB interpreter 
incorporates a command line interpreter through which, a 
user can enter commands to perform specific operations and 
tests on the USB system. The user may execute commands 
in an operating system (e.g., Unix) shell without having to 
interrupt a USB testing or debugging session. The user may 
also enter commands and perform USB system testing 
remotely via a communications link between the user and 
the system's host computer. 

29 Claims, 6 Drawing Sheets 
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UNIVERSAL SERIAL BUS INTERPRETER The implementation of plug-and-play capabilities through 

the USB is not solely dependent upon the USB. It is 

BACKGROUND OF THE INVENTION fundamental that the peripheral devices to be installed on the 

USB must be compatible with the USB. In other words, it is 
L Field of the Invention 5 necessary that the devices conform to the specific charac- 
The invention relates generally to computer systems and teristics of the USB. This is ensured in pari by the propa- 
more particularly to methods and devices for testing the gation of the USB Specification, which defines these char- 
functional compatibility of peripheral devices with a uni- acieristics. The USB Specification is hereby incorporated 
versal serial bus. herein by reference in its entirety. The designs of peripheral 
~ - ... rtf ( . ~ ,„ Q „ t Art in devices can be checked prior to manufacture through device 
2. Description of the Relevant Art 10 Such verification of device designs, however. 
Since the advent of personal computers, computer users may themselves contain errors. Additionally, errors may be 
have been eager to expand the capabilities of their machines. introduced in translation of the design into a physical device. 
Users, however, have experienced innumerable difficulties Ji is therefore important to have means for verifying different 
when confronted with the task of connecting peripheral aspects of USB compatibility of peripheral devices in their 
devices to their computers. While it may be simple for a user 15 final physical configurations. It is also important to have 
to auach a printer to his or her computer, the connection of means for verifying USB system functions apart from the 
a device (e.g., a scanner) to a serial port presents more of a peripheral devices. The various embodiments of the inven- 
challenge. The installation of equipment internal to the tion provide such means, 

computer, such as an interface card for a scanner, may One embodiment of the invention comprises a USB 

present even greater difficulties, as the user may face prob- 20 interpreter. The USB interpreter is a software tool that can be 

lems in setting I/O and DMA addresses for resolving IRQ used in a USB system to selectively examine device data, 

conflicts. These difficulties can frustrate the user, partial- execute USB commands and exercise USB functions. The 

larly when they cause the computer to operate incorrectly or USB interpreter can perform these functions ^without having 

simply fail to operate at all. 10 » * test program and can therefore be very 

„V. ^ j .25 useful in debugging devices with respect to USB comph- 

With the rapid advances in the state of computer » ^cc. ITie USB interpreter can also be used in the develop- 

technology, the potential for experiencing such difficulties menl 0 f rjSB software 

has grown. There have, as a result, been attempts to alleviate ^ USB ^rcter comprises a test application and a 

these problems. For example, the concept of designing test application driver. The test application driver interfaces 

phig-and-pLay peripheral devices was intended to alleviate ^ to USB software. The USB system software, 

difficulties of installing the devices. This concept, however, which may include a USB driver, a host controller driver and 

is directed primarily toward devices which are installed othcr hosl software, is sometimes referred to as the USB 

inside the cabinet of the computer. The installation of framework support. The USB driver interfaces with the test 

external peripheral devices, such as printers and scanners, is application through the test application driver. The hosl 

still likely to be accompanied by some of the difficulties ^ controller driver interfaces with the host controller, which in 

targeted by the plug-and-play concept. turn interfaces the software on the host system with the USB 

Another attempt to eliminate some of the problems atten- interconnect and USB devices, 

dant to the installation of peripheral devices was the intro- j D onc embodiment, the USB interpreter incorporates a 

auction of PC-Card technology. (This technology was for- command line interpreter through which a user can enter 

merry termed PCMCIA — Personal Computer Memory Card ^ cc^rimands to perform specific operations and tests on the 

International Association.) PC-Card (PCMCIA) peripheral USB system. The user may thereby avoid performing unnec- 

devices are simply and easily inserted into a PC-Card socket essary ***** on previously verified portions of the system, 

and are recognized by the computer. The problem with this The use of the command line interpreter further allows the 

technology, however, was that it was originally targeted to ^ 1SCT to execute commands in an operating system (e.g., 

portable computers. Although a PC-Card (PCMCIA) slot 45 Unit) shell without having to interrupt a USB testing or 

can be installed in a desktop computer, this solution simply debugging session. The use of the command line interpreter 

has not been widely adopted. Thus, there remained a need a^ allows the user to enter commands remotely (e.g., via 

for a simple and convenient plug-and-play type technology a modem connected to the computer system) so that the 

for desktop computers. expertise of a user who is not located at the site of the 

50 computer system. 



SUMMARY OF THE INVENTION 



BRIEF DESCRIPTION OF THE DRAWINGS 



One or more of the problems outlined above may be _ . . . , . . m - . . ... 

solvedbyvrionsembodtoentsofthesyslemandoothidof ™ zr objectt .nd advantages of d» loyenuoo wiB 

solution to the problem, the idea of a universal serial bus 111 w 

(USB) was developed. The development of the USB was *IG. * * • block diagram flrustra^g the physical con- 

mouvaled by number of factors, including the difficulty of fi ^ ton of a P lurabt y of USB P^npheral devices attached 

adding peripheral devices and the lack of actional ports for to a computer system. 

installing these devices. The USB is designed to provide 60 FIG. 2 is a block diagram illustrating the primary physical 

plug-and-play capabilities for external peripheral devices components of a USB system. 

which are connected to the I/O ports of the computer and FIG. 3 is a block diagram illustrating the tiered star 

thereby reduce the difficulties experienced by many users. physical configuration of a plurality of devices connected to 

The USB was also designed to provide means for installing hubs on a USB interconnect. 

numerous devices rather than restricting the user to one or 65 FIG. 4 is a block diagram illustrating the simple star 

two (one for each port on a computer which does not have logical configuration of a plurality of devices connected to 

a USB). a USB interconnect 
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FIG. 5 is a functional block diagram illustrating the 16 on the computer system via hubs 17-18. The use of bubs 

logical and physical flows of data within a USB system. 17-18 on the USB enables users to expand the number of 

FIG. 6 is a functional block diagram illustrating the devices which can be connected to the computer system (as 

logical and physical flows of data within the host in a USB compared to the two or three which could be directly 

* lem 5 connected to a non-USB system.) The system may also 

FIG. 7 is a diagram illustrating the flow of data between *4ude compound devices 12 which serve as both bubs and 

client software inlhe USB hostTnd a plurality of endpoints devices (Note tfut *v» 13 tsconnected to the 

in a USB device. USB vw com P OUI,d tt > 

FIG. 8 is a diagram illustrating the structure of the USB |A Referring to FIG. 2, a block diagram iUiistrating the 

test application in one embodiment of the invention. 10 P™*? physic^ components of a USB system is shown. 

, . - « A . The physical USB system can be described in three parts; a 

While the invenuon is susceptible to various rnodifica- USB devices 22; and a USB btcrconnecl 21. 

lions and alternative forms, specific embedments thereof ^ arts>lhcUSB host, is the computer system 

are shown by way of ean.pk m the drawu^ and wdl j^^Lfe USB root hub andfbrms U* baVisof 

berem be described in detail It shouM be understood, , 5 ^ ugB ^ 

however, that the drawing and detailed deacon thereto J^Xpe*£berals and ^ whicharc to be 

are not ujtended m Imnt the mven^on to Je par^^&mB l^Jfib* computer system. USB "devices" may also 

dsclosed but on die contrary, ttie inWnUon is to jover all the bubs which can be connected to the USB to 

moiflcauons.equivalents and aheraaUves fclhng wubin the aUachmenl ports. He third pari, the USB 

spirit and scope of the present invention as defined by the „ gj£ ^ lbe between 

appended claims. ihc USB devices and the USB host, as well as the m inner in 

DETAILED DESCRIPTION OF THE which the devices communicate with host 

PREFERRED EMBODIMENTS There is a single host associated with any USB system. 

One embodiment of the invention is described below. In M ™. B h °* * *° S^SiSStS^ 
tMs embodiment, a host computer utilizes a USB system. a implernented. The host m«^rate a^t hub of the £SB 
IrJr 7Z rC^ . " «: 11ct> . ^ which provides one or more attachment points for devices or 

The USB system mcrudes a US* a USB tost ^troHer h ^ A host controller provides the interface between 

coupled to the USB, a host «Mu driver fcrdnvmgthe USB . ^ Lt controller may be tople- 

host controUer and a set of USB mtofaces which aflow xt of hardware, firmwaZnd 

communications between a test application and the host 30 Jr~ 

controller driver. The test application comprises a USB software. , t . 

interpreter which is used to selectively test the Suctions of The USB devices are Junctional devices which provide 
the USB system. Specifically, the application is configured capabilities 10 the system (e.g., an ISDN modem, a joystick 
to exainine standard device descriptors, query USB devices or a set of speakers.) The USB devices may also bchubs 
using standard device requests and exercise individual USB 35 which provide additional attachment points to the USB to 
interface functions. The USB interpreter allows the user to which additional devices may be connected. (Non-hub 
take these actions without having to first create and compile devices are sometimes referred to as functions.) Some USB 
a test application. The USB interpreter thereby allows a user devices serve as both fimchraal devices and hubs to which 
to selectively obtain information which facilitates debug- other devices can be attached. The USB Specification 
ring of USB devices and related software. 40 re< * uircs ^ a11 USB dcvices <^°™ to ^^face 

le development of the USB was motivated primarily by and thereby ensures that the devices comprehend 

three considerations. First, personal computers have tAdi- the USB protocol and respond to standard USB requests and 
UonaHy had limited flcxfoilft^ commands. 

the computet A number of advances were made in the areas The physical aspects of the USB interconnect are defined 
of graphical user interfaces and internal bus architectures 45 by ^ bus topology. (Although the bus topology includes 
which made personal computers more user-friendly, but non-physical aspects of the USB interconnect, they will be 
there was little progress in improving the connectivity of addressed elsewhere in this disclosure.) The bus topology 
peripheral devices to desktop systems (despite the success of describes the manner in which the USB connects USB 
PC-Card plug-and-play peripherals in portable computers.) devices with the USB host Referring to FIG. 3, the physical 
Second, personal computers typically had a limited number 50 configuration of the USB interconnect is that of a tiered star, 
of ports to which peripheral devices could be connected. A The host has a root hub which forms the basis of the 
typical system, for example, might have a single parallel interconnect. Devices and/or additional hubs can be con- 
port and one or two serial ports. Users were therefore nected to the root and other hubs to form successive tiers of 
prevented from having more than two or three peripheral the interconnect Thus, each bub forms the center of one of 
devices corresponding to the two or three ports on their 55 the stars in the tiered star configuration. Each wire segment 
computers. Third, although there has been significant poten- in the interconnect is a point-to-point connection between 
tial for computing and communication functions to benefit the host or a hub and another hub or a device, 
from each other, these technologies have evolved essentially USB systems support "hot plugging". That is, USB 
independently so that the technologies were not easily devices may be attached to or removed from the USB at any 
merged. There was therefore a need for an easy and inex- 60 time. The USB is designed to detect these changes in its 
pensive means to communicate information via computers. physical topology and accommodate the changes in the 
The USB was designed to meet these needs. available functions. All USB devices are connected to the 

Referring to FIG. 1, the USB is a bus designed to provide USB at one of the hubs (either the root bub or one of the 
a simple and efficient method for connecting external hubs chained from the root.) Attachment or removal of a 
peripheral devices to desktop computer systems. The figure 65 device at a bub is indicated in the hub's port status. If a 
shows a computer system 10 connected to several peripheral device is attached to the hub, the hub sends a notification to 
devices 11-15. The devices are connected to the USB port the host. The host then sends a query to the hub to determine 
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the reason the notification was seal to the host Id response flow is illustrated in the figure by the arrows.) The number 
to Ibis query, the bub sends the number of the port to which of each eodpoint is determined by the designer of the device, 
the device was attached to the host. The host then enables The combination of a device address (assigned by the 
this port and begins communicating with the device via the system at device attachment time) and the cndpoinl Dumber 
conirol pipe (0 endpoint.) The host determines whether the s altows each endpoint to be umquely identified, 
attached device is a hub or a function and assigns a unique All USB devices are required to have an cndpoint with 
USB address to the device. The unique USB address and the number 0. This endpoint is used to initialize and manipulate 
0 endpoint of the device are used as a control pipe for the to configure) the logical device, Endpoint 0 provides 

device If the newly attached device is a bub which already **ess to the device's configuration information and allows 

, , . ^.u j . ^ .lv _~v~<^ L ,« access to the device for status and control purposes. Devices 

has devices ^mM^ue^^^ process is io OTbavcaddi&Dde ^^ 

repeated for eadr of tte attached dev^ Devices can have up to 16 additional input 

been attached and communications "tabbed between the ^ ^ lfi ^ ^ ^ £ 

device and the host, notifications are sent to interested host m ^ m *pe*d devices, in which case they are limited to 
software. ^ a reduced number of endpoinls.). 

If a device is removed from a hub, the hub disables the 15 The communications path between an endpoint on a 
port to which the device had been attached and sends device and software on the host is referred to as a pipe. A 
notification of the device's removal to the host. The host pipe comes into existence when a USB device is configured, 
then removes the device and related data from any affected Software clients normally request data transfers via I/O 
data structures. If the removed device is a hub to which other Request Packets (IRPs) to a pipe. The software clients then 
devices arc attached, the removal process is repeated for 20 either wait or are notified when the requests are completed, 
each of the devices attached to the removed hub. Notifica- Endpoint 0 has an associated pipe called the Default Pipe, 
tions arc sent to interested host software indicating that the The Default Pipe is used by system software to determine 
removed devices are no longer available. device identification and configuration requirements and to 

Although the physical topology of the USB interconnect configure the device. The Default Pipe can also be used by 
is that of a tiered star configuration, the logical topology of 15 device specific software after the device is confipred but 
the system is a simple star as shown in FIG. 4. Alternately, the USB system software retains "ownership" of the Default 
the logical configuration can be considered a series of direct Pi P c and controls its use by client software, 
connections between the individual USB devices and a Referring to FIG. 8, the software structure of one embodi- 
ment software application on the host The logical relation- menl of the invention is shown. The client software in this 
ship of the client software to the devices can also be thougbt 30 embodiment comprises a test application 30 and a test 
of as one or more direct connections between the client application driver 31. The USB system software 32 cam- 
software and the specific functions provided by the devices. prises USB driver 33 and host control driver 34. The USB 
While the view of the logical configuration as being a series driver 33 and host control driver 34 are part of the USB 
of direct connections holds true for most operations, the Framework Support. The USB Framework Support is a 
system remains aware of the tiered physical topology so that 35 Solaris© based implementation of the USB system soft- 
devices downstream from a removed hub can be removed ware and includes a set of interfaces (USB Architecture 
from the logical configuration when the hub is removed (see Interfaces, or USBAJ) which allow third party vendors to 
the discussion of hot-swapping above.) write USB client drivers on a Solarise SPARC® plat- 

The USB provides means for communications between ^ form, 
client software running on the host and functions provided jest application 30 includes modules configured to con- 
by the USB devices. FIGS. 5 and 6 illustrate the flow of data \xq\ testing of the different functions of the USB system. Io 
which is communicated between the client software and the instance, the separation of the modules' capabilities 

device functions. The figures show the host as comprising generally conforms to the separation of USB functionalities 
three components: the client software; the USB system 4S defined in the USB Specification. For example, one module 
software (including USB driver, host controller driver and 35 controls the testing of standard device requests defined in 
host of software); and the USB host controller. The host Chapter 9 of the Specification, while another module 36 
controller driver interfaces the host controller with the USB controls testing of hub standard requests as defined in 
system software, and the USB driver interfaces the USB Chapter 11 and another module 38 controls the testing of 
system software with the client software. FIG. 5 shows that JQ USBAI functions. Interpreter module 37 does not provide 
the USB device also comprises three components: the funcv for the testing of a separate set of functions, but instead 
tion; the logical device; and the USB bus interface. supports testing of all of the USB functions. These modules 

While the logical flow of information between the client are all operatively coupled to the body 39 of the test 
software and the function is direct, the figure shows that the application* 

actual flow of data goes from the client software to the USB 55 Test application driver 31 is similarly structured, having 
system software, to the USB host controller, to the USB bus a main driver component 40 and several modules 41-44 
interface, to the USB logical device and finally to the which correspond to the modules of application 30. Test 
function. likewise, although the logical flow of control application driver 31 is a loadable driver. That is, when a 
information from the USB system software to the USB USB device is hot-plugged, the USB architecture framework 
logical device is direct, the actual flow of information must 6o will load the driver and create a device node for the newly 
go through the host controller and the bus interface. installed device. If the device is hot-unplugged, the driver 

Referring to FIG. 7, a USB logical device is viewed by the will be unloaded as to the unplugged device. 
USB system as an interface formed by a collection of The test application may be run on any USB device after 
endpoinls. An endpoint is a uniquely identifiable portion of it is installed. In one embodiment, the application, which is 
a USB device that forms the end of a communications path 65 controlled primarily by the interpreter module, takes a 
from the host to the device. Software may only communicate device node as an argument, opens the device node and 
with a USB device via its endpoinls. (The communications constructs state information for the device based on descrip- 
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lor information obtained from ihe device. Test application utilize any suitable means for communicating, and the 

driver 31 maintains the device state for use in testing the foregoing example of a modem-based link is intended to be 

device. System test resources are allocated based on the illustrative rather loan limiting. 

constructed state information. The slate information is also The user may also execute commands which are unrelated 

used as the basis of lest requests which may be formulated S to me lest system (e.g., Unix shell commands) without 

by application 30. The test requests are forwarded to USBI having to interrupt the test session. The lime normally 

module 43 of the test application driver 31 v which decodes required to start and terminate other test systems to perform 

and validates the test parameters. If tbe test parameters are non-system functions may therefore be avoided. The com- 

vdkl (i.e<> within the allowable limits of the parameters,) the mand line mode can be configured to alias the available 

test application 30 and application driver 31 construct test to commands to a unique list to reduce tbe amount of typing 

cases using USBAI functions. The corresponding function which is required. Tbe lest system can also be configured to 

calls are transmitted to tbe USB driver, which executes the provide online help to facilitate the user's interaction with 

functions. Test application driver 31 updates tbe state infor- we system. 

maiion for tbe device when the function calls are issued and One embodiment of the test system is configured with a 

notifies test application 30 of the pass/fail status of the tests 15 functional mode in which the system can single-step through 

after the test functions are performed. Test application 30 a USBAI function. This may be useful when the user needs 

then notifies the user. to examine traffic on the USB. After a USBAI function 

In one embodiment, the test application runs a suite of command is issued, USB traffic may be examined using a 

tests to verity all of the USBAI function calls. The appli- kfcic analyzer as each step of tbe function is performed. This 

cation opens a device node, constructs stale information for 20 can be a valuable debugging feature, 

tbe device and allocates system resources based on tbe state Another feature which may be included is the capability 

information. Tbe USBAI module 38 of tbe test application 0 f switching ports during testing. As mentioned above, the 

30 formulates test requests and parameters based on the state system is configured to perform device enumeration . That is, 

information and conveys the test requests and parameters to wheo there are multiple USB devices connected to the 

the USBAI module 42 of the test application driver 31 for 25 system, it can list all the connected devices and construct 

validation. After validating the test requests and parameters, state information such as port number, device type, device 

tbe USBAI module of the test application driver formulates class and path for each of the devices. The user can select the 

a series of test cases using the USBAI functions. The USBAI device at a particular port for certain tests and tben switch to 

module of the test application driver then makes USBAI a different port and lest the device connected to that port 

function calls corresponding to tbe test cases to the USB 4A . . ... . . . . . t r r «u 

system sofrwarT^SBAI module of the test application 30 b ^*onto detenn^g device ^formaUon for the 

driver returns a pass or fail indication to the test a&ication * JfnSST 

after analyzing me results of tbe function calls. This same configured to make tta information available to the user, 

pro^ ferepLed for all of tbe endpoints in the selected WormaUon such as device £eq£n can .be flayed m 

USB device Tbe test application may spawn multiple * **** form * 1 * en^lethe user to mate sj^^y-side 

uiieads tc^now c<mcurrtnt^ting of tbe diifcrem endpohTts. * * ^ characteristics * **vidual advices, 

^••^k^^;™^ Because bus enumeration is an ongoing activity in the USB 

^,^^^hS^ *^ concurrent testing dcviccs m rccognizcd aslhcy are connected to the 

of multiple USB devices. USB and the information which is normally obtained on the 

In a similar manner ibc ;test applicauon may run a suite devi£es ^ ^ d alongside infonnation for prcvi . 

of tests to verify that a USB device can 1 p^e ar^ropnale ousl Evicts. likewise, information correspond- 

device infection in response to all of the standard device 40 7 m femovcd fom mc USB ^ m 

requests defined in the USB Specification. The application amoved from tbe display, 

again opens a device node, constructs slate information for J 

the device and allocates system resources based on tbe state In one embodiment, the commands which can be input to 
information. All of the standard device requests arc pack- the test system can be grouped into four categories: com- 
aged in a request structure which is passed to the test 45 mands relating to device state infonnation; standard device 
application driver. The Chapter 9 module 41 of the test request commands; USB architecture interface commands; 
application driver 31 validates tbe commands in the request and miscellaneous commands. Although a number of these 
structure and then conveys the requests to the USB device commands axe listed below, this list is not intended to be 
via the Default Pipe. Tbe information provided by tbe device limiting. It is contemplated that the USB Specification may 
in response to the standard device requests is tben returned - Q be amended to add, delete or modify the allowed commands 
to tbe test application. to accommodate the changing functionality of tbe USB, and 
Different embodiments of the invention may include f*l system may be adapted to include the new corn- 
various features. One such feature is a command line mode. mands and functions of the USB. 
In command line mode, a user may input individual com- 7^ device state information commands are shown in 
mands which are interpreted and executed by tbe application 5J T^Je 1 along with their corresponding functions. Device 
to test particular functions of the USB system. This can S late information is tracked for the devices enumerated and 
eliminate unnecessary testing which would be performed by identified by the test system. When an endpoinl of a device 
a comprehensive suite of tests. Commands may, however, accessed, its slate is updated in the test system, 
also be set up to execute a series of operations instead of a 

single operation. TABLE 1 

The command line mode also allows the test application 60 ^ — 

to be used remotely. In other words, the user does not have status Usu port number, device cUo »ad device 

to be physically present to test the USB system. The user ^^^^^ 

may instead establish communications with the test system command!) 

and enter commands through the communications link. For Enumciate Probes ill available USB device nodes tod 

example, the user may establish a modem connection 65 cre&ia device sate information for each of 

between a remote computer and the test system and men uw connected USB device*, 

enter commands via the modem connection. The link may 
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TABLE 1 -continued 



TABLE 3 



Device_rtnie 



Port 



Used to switch from e port si which one 
device it attached lo aaotber port at which 
b second device is eouocted, (The port 
Dumbert can be obtained from the "status" 
and.) 



ao 



The standard device requests arc defined in Chapter 9 of 
the USB Specification . The standard device requests are 
shown in Table 2 along with their corresponding functions. 
All USB devices axe required to respond to standard device 
requests from the host. These requests are made via the 
device's default pipe using control transfers. The request and 
the request's parameters are sent to the device in the setup 
packet 



15 



20 



TABLE % 



25 



30 



GeL-Sifttut Used to obtain status Cor a device, interface 

or endpoint Device statu consists of a 
remotc_wakeup value corresponding lo 
cither enable or disable. The returned status 
in the Interface field must be zero. The 
returned status of an endpomt can be either 
stalled or not stalled. 

clear_feature Used to dear or disable two fatuie selectors; 

DEVTCE_REMOTE_WAKEUP £or the 
device; or ENDPOINT_STALL on a specific 
midpoint address. The endpoint address can 
be obtained from the *get_descriptor or 
H deviee_state M commands. 

acU&aauo Used to set or enable two feature selectors: 3$ 
DEVlCE_J*EMOTE_WAKE f JP for the 
device; or ENDPOINT_STAlJL oa a specific 
endpoint address. The endpoint address can 
be obtained from the "geLjieunifrtor" or 
"devices-stale" commands. 

tet_addret* Used only by system software. 40 

get_descriptor Used to return the descriptors for device, 
configuration, suing or hub descriptors. Alt 
devices must provide a device descriptor and 
at least one configuration descriptor. The 
command reuiras the bub descriptor only in 
the device a in the hub class. 

seL-descriptor USB devices usually do not support this 
command. The stall condition should be 
returned. 

geLjeonfig Returns the current configuration value. If 

the returned value is 0, the device is not 
configured. If the device Is configured, a 
non— 0 configuration value is iq turned. 

sct_£onfig Used to set die configuration value of the 

configuration des c riptor. 

get_interfocc Used by the boat to determine the currently 
selected alternate setting. 

set_inler&ee Used by the host to set a selected alternate 

setting of an inLcrrnce. 55 

syach_Jiame Used only for isochronous devices. This 

command should generate a stall condition. 



60 

The U5BAI commands are shown in Table 3 along with 
their corresponding functions. The USBAI commands are 
issued to a particular endpoint of a selected device. The 
USBAI functions corresponding to these commands can be 65 
executed in single-step mode in order to allow the user to 
examine traffic on the USB. 



45 



50 



opcn_pipc Used to open individual endpoiats of USB 

devices. The open_pipe command takes an 
endpoint index as an argument for opening 
the pipe. The endpoint index can be obtained 
from the "dcvice_sutfe* t command. 

r\r*» p?p*>- Used to close individual errfpointe. This 
oommsad takes an endpoinl index as an 
argument for closing the pipe. The endpoint 
must be opened before it can be dosed. The 
endpoinl index can be obtained from the 
*devieo_ttate" command. 

suvL-polltng This command applies only to an interrupt 
endpoint It a invalid if Ibe argument is a 
non-interrupt endpoint. Before an interrupt 
endpoint can be polled, it must be opened 
using the •'open-pipe" command. The 
endpoinl index can be obtained from the 
M device_state" command. 
Most USB devices need some hardware 
event lo generate an interrupt packet after the 
endpoint is polled 

itop_polling Tbifl command applies only to an interrupt 
endpoinL Polling must be started before it 
C8D be ■lopped. The endpoinl index can be 
obtained from the "dcvice^jjlnlc" command. 
This command returns an error If the 
■sUrt_poUiag H has not been executed on the 
endpoinL 

teCpolicy Sets the pipe policy. (Bach pipe has a set of 

pipe policies. The policy allows the system 
software to change the behavior of the pipe.) 
The height must be opened using 
"opem-pipe" before the policy can be fret 
The two policy fields which can be set by the 
user are pp_rrtirx_nnlinindiaB.. request and 
pp_pcrio cJcL^*jr_trajsfer_sixe. 

get_pobcy Used to read the pipe policy. The pipe most 

be opened using the "cpeiL_pipe" command 
before fee policy can be read. 

react Used to clear and released the associated 

resources allocated by the software. The 
pipe must be opened wing the "opdL-pipc* 
mmmatid before the pipe can he reset 

c3ear__pipc Used to perform a ptpe_jeset on the control 

endpoint This command is usually used 
when (here is a stall condition. 

seUprivate Used to set a private data ares in the USB 

client driver. This command is used to verify 
the iub_pipe_$eL - privgte USB architecture 
interface function. 

get-private Used to obtain private data that was set in Ibe 
USB client driver. The seU-piivate command 
must be used before the getlprivate 
eommand. The gpl_private command returns 
an error if the pipe la not been opened or if 
the iet_privale command has not been 
e xe cuted. 

reserve Used to reserve a pipe of in endpoint index 

by calling uib_p [pe_re*ervc in Ibe USBl 
module of Ike USB diem driver. The pipe of 
the endpoint must be opened before the pipe 
can be reserved. 

release Used to release a pipe of an endpoinl index. 

Thui eommand c&Ui uab_pipe_rcleaBe. The 
pipe of an endpoinl must be opened and 
reserved before the pipe can be released. 

gel_addr Used to perform the usb_8et_*ddr USB 

aicMtectnre interface call oo an endpoinl 
index. The pipe must be opened before this 
comnund era be used. 

interfaced Used to perform the 

usb_gcOnteTfkcc_mimbcr USB architecture 
interface call on an endpoint index. The pipe 
must be opened Venire this command can be 
used. 

get_dcv_desc Used to perform the usb_geL.dev_deac USB 
architecture interface call oo an endpoint 
index. The pipe must be opened before this 
command can be used. 
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9. The lest system of claim 8 wherein said test application 
TABLE 3-continued & configured to enumerate said one or more USB devices 

and to display data representative of said enumerated USB 



mw_amfl8 Used to perform the usb__£euriw_ccmfig devices to said user, and w herein said test application is 

J^T^T?^^* 5 fibber ^configured to enable selection of one of said enu- 

before this command can be used. merited UbB devices. 

— —___^___— ^^^^__ 10. Tbe test system of claim 8 wherein said test applica- 
tion is configured to enumerate said one or more USB 
In addition to the foregoing commands, the (est applies- devices and wherein said lest commands are configured to 
lion provides for the following miscellaneous commands designate a particular one of said USB devices for said 
(see Table 4.) 10 operation. 

11. Tbe test system of claim 10 wherein each of said USB 
TABLE 4 devices has one or more endpoints and wherein said lest 

— ^— — _ _ __ ^__ ^^_ commands are configured to designate a particular one of 
*W hclp utflay 01 endpoints for said operation. 

qnit/exii ^nfaSS'tbe tot application. 15 . 12 - The test system of claim 8 wherein said lest applica- 

•beef ReiuriM data itructufe tUe for device, tioo and said USB system software are configured to rec- 

configu ration or eodpoint descriptors. ognizc attachment of one or more additional USB devices to 

— — - — — «— — _ - USB interconnect and wherein said test application and 

„ . ... t_ J said USB system software are configured to recognize 

While the present invention has been described with 20 remova ] 0 f 00 e or more of said USB devices to said USB 
reference to particular embodiments, it will be understood interconnect. 

that the embodiments are illustrated and that the invention 13. The test system of claim 8 wherein said test applica- 
scope is not so limited. Any variations, modifications, addi- tion is configured to stoic state information associated with 
tions and improvements to the embodiments described are at least one of said USB devices, 
possible. These variations, modifications, additions and ^ 14. The test system of claim 8 wherein said test applica- 
improvements may fall within the scope of the invention as tion is configured to establish one or more pipes between 
detailed within tbe following claims. said test application and one or more corresponding end* 

What is claimed is: points in said USB devices. 

1. A test system for determining compliance of a universal 15. The test system of claim 1 wherein said USB system 
serial bus (USB) system to a set of predetermined specifi- 30 operation is a multi-step function and wherein said lest 
cations comprising: system is configured to execute said USB system operation 

a computer system wherein said computer system is m a single-step mode, 
configured to execute a test application and USB sys- ^ test system of claim 15 further comprising a logic 

tern software and wherein said computer system analyzer coupled to said USB interconnect, said bgic ana~ 
includes a host controller, « lvzcr coiifigured to generate data indicative of signal 

a USB interconnect coupled to said computer system and lraffic . on USB USB S ^ CID 

configured to be controlled by said host controller; operation. . 

... . 17. A method for testing a function of a universal serial 

wherein said computer system is configured to accept test wmcm«^Tof , JS iiQnT^m h.Jm, 

commands from a user, execution of each of sakl test h} f^ B ) SystC ?° f a «^%^ d USB svstem Davin B 
WflumftU , . . 0 7 . . , .. , r~~ a USB interconnect one or more USB interfaces and one or 

commands being associated with a OTiresponding USB 40 ■ ~ ^S^ZSlT JJ^a r«™£,w 
system operation, said operation being performed upon morc U ? B dcVICCS ' lhc m f °* ""V™"* 
execution of said test command. CDlenn 8 a lcsl conmand on said computer; 

2. Tne test system of claim 1 wherein said computer interpreting said test command using a command line 
system comprises a Unix operating environment, wherein interpreter; 

said test application comprises a command line interpreter 45 executing an operation associated with said test com- 
configured to accept said lest commands via individually mand; 

entered command lines and wherein said user may enter transmitting a test signal to said USB system; and 
both Unix commands and said test commands, said test validating a test result generated by said USB system in 
commands being executed by said test system and said Unix response to said test signal. 

commands being executed by a Unix shell. SO 18. Tbe method of claim 17 wherein said operation is a 

3. The test system of claim 1 wherein said test application USB interface function and wherein said test signal is 
is configured to perform a predetermined series of said transmitted to one of said USB interfaces of said USB 
operations in response to a user input. system. 

4. The test system of claim 3 wherein said series of 19. The method of claim 17 wherein said operation is a 
operations comprises a set of USB standard device requests. 55 standard device request and wherein said test signal is 

5. The test system of claim 3 wherein said series of transmitted to one of said one or more USB devices of said 
operations comprises a set of USB architecture functions. USB system. 

6. The test system of claim 1 further comprising a 20. The method of claim 17 wherein said computer 
communications link between said computer system and a system is coupled to a remote location via a communications 
remote location and wherein said test commands are entered 60 link and wherein entering said lest command comprises 
into said computer system from said remote location via said entering said test command at said remote location and 
communications link, transmitting said test command over said cornnrunications 

7. Tbe test system of claim 6 wherein data generated as a link to said computer system. 

result of execution of said test command is transmitted to 21. The method of claim 17 further comprising entering a 
said remote location via said communications link. 65 shell command on said computer and executing said shell 

8. The test system of claim 1 further comprising one or command in an operating system shell running on said 
more USB devices coupled to said USB interconnect computer. 
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22, The method of claim 17 wherein executing said 
operation occurs in a single-step mode. 

23. A method for testing a universal serial bus (USB) 
system, the USB system including a host computer system, 
a USB interconnect coupled to the host computer system and 
one or more USB devices coupled to the USB interconnect, 
(be method comprising: 

creating a node corresponding to one of said one or more 

USB devices; 
opening said node; 

obtaining state information for said one of said one or 

more USB devices; 
storing said state information; 

executing one or more tests based on said state 
information, each of said one or more tests correspond- 
ing to a particular function of said USB system; and 

validating the results of said one or more tests. 



10 



is 



14 



24. The method f claim 23 wherein creating said node 
comprises enumerating said USB system to identify said one 
or more USB devices and creating nodes for said devices. 

25. The method of claim 24 wherein obtaining state 
information for said one of said one or more USB devices 
comprises requesting one or more descriptors from said one 
of said one or more USB devices. 

26. The method of claim 25 wherein said tests comprise 
tests of USBAI functions. 

27. The method of claim 26 wherein said tests further 
comprise tests of standard device request functions. 

28. The method of claim 25 wherein said tests correspond 
to one or more command lines entered by a user and 
interpreted by a command line interpreter. 

29. The method of claim 28 wherein entering said com- 
mand lines further comprises transmitting said command 
lines to said computer system from a remote location. 
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(57) ABSTRACT 

A reply descriptor for transmission over an I/O message 
passing medium in response to a corresponding request 
message, the descriptor comprises at least one indication 
field that can function as a 'flag* to identify its type, and a 
content field; whereby a reply message is generated only if 
at least one predefined condition is sot met and the content 
field will, accordingly, comprise information of that reply 
message's storage location. The content field to comprise 
data copied from the I/O request message if each predefined 
condition is met. A method of responding over an I/O 
message passing medium to a request message comprising 
the steps of: generating a reply message to the request 
message only if at least one predefined condition b not met; 
generating a reply descriptor having at least one indication 
field and a content field; whereby the content field comprises 
information of the reply message's storage location if so 
generated. Also, a program code on a computer readable 
storage medium comprising: a first program sub-code for 
generating a reply message to a corresponding I/O request 
message only if at least one predefined condition is not met 
The first program sub-code comprising instructions for 
generating a reply descriptor having at least one indication 
field and a content field that comprises information of the 
reply message's storage location if said reply message is so 
generated 

25 Claims, 8 Drawing Sheets 
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METHOD OF RESPONDING TO I/O software layers. The header and payload parts reside within 

REQUEST AND ASSOCIATED REPLY » physically-contiguous buffer called the message frame 

DESCRIPTOR buffer (such as is shown in FIGS. 3-19 of the I 2 0 

Specification). 

5 UO messages fall into two basic categories: (1) request 

BACKGROUND OF THE INVENTION messages initiate activity at the destination (a request may 

In general, the present invention relates to communicating contain multiple transactions of the same type); and (2) reply 
message information, or data, over message passing messages return status information concerning one or more 
interface^) between program modules, such as a target requests. According to JqO convention, a reply message is 
peripheral device module and an operating system (OS) io generated and sent for every request (see I 2 0 Specification 
module within an I/O system, whether the modules are sections 6.1.2 and 6 .4.4), regardless of whether the request 
executed on the same or different digital computer proces- was completed without error (see section 6.4.42.1 of I 2 0). 
sors and whether utilizing different operating systems. Of I 2 0 convention classifies all messages, each class has a 
particular interest is the message reply portion of the com- format for request messages and a protocol for generating 
munication between I/O system modules to f eventually, send 15 and transmitting reply messages for mat class. For example, 
status information back to the caller (e.g., an operating * utility messages* are common to all message classes, and 
system) that issued the original command, regardless of the messages specific to a particular message class are 'base 
specific communications protocol and interface technology class messages 4 . According to the I 2 0 Specification, 
employed. More particularly, the invention relates to a inbound and outbound queues are reserved for each I/O 
unique method of responding over an I/O message passing 20 platform (referred to mere in as "IOP" — see FIGS. 2A and 
medium to a corresponding request message, by way of an 2B schematically outlining the relationship between a host 
associated novel reply descriptor transmitted in response platform, an IOP1, and IOP2). Note that the I 2 0 Spedfica- 
thereto. tion uses IOP synonymously with an 'I/O processor entity 4 

Within an I/O system, typical computer hardware includes dedicated to processing I/O transactions (consisting of 
a host system entity connected to communicate with one or 25 processor, memory, and I/O devices). The inbound queue of 
more I/O devices. The trend in development of I/O system an IOP receives messages from all other platforms, includ- 
aichitecture is to utilize a split driver model, see FIG. 1, as ing the host system, and the outbound queue of each IOP 
explained more-folly in a Version 2.0 of the "Intelligent I/O collectively function as an input queue for the host system. 
Architecture Specification" dated Feb. 11, 1999 (herein Thus, each IOP provides support for passing messages 
referred 10 as simply "I^O Specification''), the written work 30 without requiring additional host system hardware. Once 
product of the coUaboralive effort of several commercial IOPs establish connection, the program modules at each end 
entities including the applicant hereof. Within the split of the connection can send and receive messages (generally 
driver model two basic software modules are defined, each in an asynchronous fashion as non-blocking by nature). In 
of which can execute on different physical processors and the specific case of an SCSI Controller, for example, it is the 
within different operating environments: (1) an OS-specific 35 SCSI hardware device module that detects and registers 
module (OSM) which provides an interface to the operating devices connected to the SCSI bus— and these devices are 
system (OS); and (2) a hardware device module (HDM) accessible through messages passed through the SCSI hard- 
which provides an interface to each I/O adapter and corre- ware device module. 

spending device. These two basic modules intercommuni- According to I a O section 6.1.2, reply messages fall into 
cale via a logical "messaging layer" comprised of a network 40 two general categories (as identified by the REPLY bit in the 
of Messengerlnstances (depicted in FIGS. 2-3 of the 1 2 0 message header's MessageFlags field): 'failed" messages 
Specification) as illustrated herein in FIG. I over which and "processed" messages. Failed messages are those that 
request messages to I/O devices and completion reply mes- cannot be processed (including messages that cannot be 
sages are transmitted to effect commands from the operating delivered or contain invalid or missing data). A request 
system rather than having the hosl/OSM directly read and 45 message "fails" when the message layer cannot deliver the 
write from and to each I/O device register. The split driver message or the target device does not understand the format 
model allows for expansion of the I/O system through of the request (e.g., unknown message version). Section 
software development, independent of both device hardware 6.1.2.1 further distinguishes a failed message from one that 
and the operating system. is processed but is unable to be successfully completed due 

I. Conventional Way to Respond to Requests per I a O Sped- so to "error": Tbe inability of a device driver module (DDM) 
fication to perform or carry out the request is referred to as an 

Additional layers of stackable drivers beyond the basic "error". Thus, a successfully completed request is one that is 
OSM and HDM can be logically defined as has been done processed without error. Note that in I 2 0, the acronym DDM 
in the 1^0 Specification to provide additional functionality is often used generically in place of specifying whether the 
between the two basic program modules. The stacking of 55 module is a hardware device module (HDM) or an interme- 
drivers increases the request and reply message load of the diale service module (ISM). 

system, in turn decreasing its speed/performance. For Section 3.4.1.2.2 of l a O specifies the template for a 
example when operating within I 2 0, on the order of 28,000 "normal single transaction reply message" as shown in 
I/O messages are transmitted per second. The ^O Specifi- FIGS. 3-23; and section 3.43.2 identifies a "multiple trans- 
cation explains in Section 3.4.1 CMessage Structure and 60 action reply message" model (wherein one or more success- 
DefinitionsT), messages are data structures that contain a fill transactions may be combined into one reply message, 
fixed-size header containing device address and payload see section 6AA.2J2 of I a O). 

description and, immediately following, a variable-size pay- As shown and explained in more detail in Chapter 2 of the 
load containing all additional information associated with I a O Specification (pages 2-19 through 2-22), whether 
the message. If the payload refers to memory, a scatter- 65 request messages are sent from the host system to a hard- 
gather list (SGL) is included in a format understandable by ware device module or are sent peer-to-peer (from one 
the originator, the target, the transport, and any intermediate hardware device module to another), all reply messages built 
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include the Initiator Address, Target Address, aod the Ini- devices. The SPI-2 working draft stales that a SCSI bus 

tiator Context field from the request message. Once the reply consists of all ihe conductors and connectors required to 

message is built, the hardware device module calls a respec- attain signal line continuity between every driver, receiver, 

live message service. The sending entity allocates a reply and terminator for each signal. In operation, a SCSI bus is 

message frame, copies the reply message into the frame and 5 a bidirectional, muliimaster bus which can accommodate 

places/writes ihe frame's address in the appropriate message peer to peer communications among multiple computer 

queue. I 2 0 FIGS. 2-13 diagrams the flow of events for its processing units (CPUs) and mulliple peripheral devices. A 

conventional process of sending request and reply messages SCSI device is one that contains at least one SCSI port and 

(I 2 0 Specification explanation reproduced below, for the means to conned the drivers and receivers to the bus. 

reference): 1° A SCSI primary bus is one that provides for and carries 

1. The operating system issues an I/O request. 8-bit or 16-bil data transfer. A SCSI secondary bus carries an 
« rr^ 0 , u , n ^ ( . additional 16-bit data bus thai, when used in conjunction 

2. The OSM (Operating System MddidiO^^te h ^ b ^ fof % ^ ^mftr 
request and translates it into a message addressed to the (a^ougTte kl£ is not, yet, widely used). SCSI 
DDM a,0 iises ^acronym DDM pnencally for ^vices ma/conoect to a bus vi^S-bit, 16-bit, o 32-bil 
hardware devicemodule HDM, or ^rmc^ate ser- / interface* devices may be 
r«^^ IS ^^^ tor Coole ^Plemented with 50, 68, or 80 pin connectors (whether 
indicate the message handler for the ^ ^OSM J unshielded As is known, a typical data transfer 
has the option to place i > pointer to Jhe OS I/O request Qn ^ a ^ bctwcen a ^ conlroller (or 
in the message s transaction context field, 2Q «Q X tocalcd m a bost computer system, to a target 

3. The OSM invokes the communication layer to deliver device ^ a disk drive) has seven SCSI "phases": (1) 
the message. ARBITRATION, (2) SELECTION, (3) RESELECTION, 

4. The host's Messengerlnstance (a collection of services (4) COMMAND, (5) DATA, (6) STATUS and (7) MES- 
that support initializing, configuring, and operating its SAGE. For example, during the COMMAND phase, a SCSI 
client modules, see FIGS. 2-3 of the I^O Specification) 25 command is transferred from the bost adapter to a target 
queues the message by copying it into a message frame (drive), and so on. Host adapter functional circuitry is 
buffer residing on the remote IOP. typically maintained on a host bus adapter (HB A) chip on a 

5. The IOP on the other end posts the message to the printed circuit board structure referred to as a host adapter 
DDM's event queue. board (HAB) for connection to a PC host via an expansion 

6. The DDM processes the request. 30 slot 

T.Afteprocessmgthemes^^ J* For Reference: Brief Background of Fibre Channel 

the DDM builds a reply, copies the initiator's context Intercormect 

and transaction coot^M* from the request to the Fibre Channel . a r*wer ^^^Jg £"[g£ 

reply, addresses the reply to the initiator, and finally **>°g with Serial Storage Archrtectnre (SSA) and i IEEE 

the message service to send it to tne originator * ™J> <*£f* of transferring ^ tt U^bttr1htiiaii 

of the remiest Ultra3 SCSI system can, over fiber opuc cabling as well as 

rwjuc . cooper transmission media. Fiber Channel-type host bus 

8-Tlie lOFs messageservu* .queues the reply by copying m mto a host 00^^ expansion slot 

it into a message frame buffer residing at the host s ^ sc$1 bost bus adapters „ installed. Fibre channel 

Messengerlnstance, ^ ejections are often associated with the term "loop" (from 

9. The IOP alerts the host's Messengerlnstance to the me Qame Fibre channel arbitrated loop) rather than "bus" 
message ready for delivery. ^ SCS j devices are connected). There are actually other 

10. The host's Messengerlnstance invokes the OSM's types 0 f p^re Channel connections, called "point to point" 
message handler with the reply. ant j "febric.** With fibre channel, communication between 

11. The OSM retrieves the pointer to the OS I/O request 45 hosts and devices does not have to be done directly. Instead, 
from the message's transaction context field to estab* users can employ bubs and switches between devices on the 
lish the original request context and completes the OS Fibre Channel network. Hubs and switches can be used to 
I/O request create Fibre Channel "storage networks". Fibre Channel 

12. The driver returns the request to the OS. cabling can be copper (can be up to 30 meters in length) or 
II. For Reference: Brief Background of SCSI 50 fiber optic (currently up to 10 Km). In addition, no termi- 

The widely-used small computer system interface (SCSI) nation is necessary for fibre channel as is required in SCSI, 

protocol was developed for industry groups, under the Fiber optic ports directly placed on ia peripheral device allow 

American National Standards Institute (ANSI) and Interna- only for connections to fiber optic cabling. Commercially 

tiona] Standards Organization (ISO) guidelines, to provide available adapters exist that allow a SCSI-compliant device 

an efficient peer-to-peer I/O bus. Devices that conform with 55 to be connected to a Fiber Channel loop, 

the mechanical, electrical, timing, and protocol requirements IV. Identification of New Method and Reply Descriptor 

(including the physical attributes of I/O buses used to The trend in I/O architecture development is toward 

interconnect computers and peripheral devices) of the SCSI stacking more layers of logical drivers and creating high 

parallel interface will inleroperale. This allows several dif- performance systems, thus increasing the request and reply 

ferent peripherals (hard disk drives, removable disk drives, 60 message overhead of the I/O system, which in turn decreases 

tape drives, CD-ROM drives, printers, scanners, optical system efficiency and performance. Therefore, a new useful 

media drives, and so 00) to be added at the same time to a method of responding to an I/O request message and asso- 

host computer without requiring modifications to the generic dated reply descriptor are needed to make messaging 

system hardware. The working draft of the SCSI Parallel between one or more hosts, one or more interconnected 

Interfflce-2 Standard (SPI-2), as modified (Rev. 16, dated 65 devices, or any host and an interconnected device, more 

Oct 14, 1997), defines the cables, connectors, signals, efficient Without a reasonable, reliable, and cost-effective 

transceivers, and protocol used to interconnect SCSI solution at band for increasing I/O system performance, 
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computer hardware and software developers will find it very Briefly described, again, ibe invention includes a reply 

difficult to meet the demand for managing more devices in descriptor for transmission over an I/O message passing 

ever-complex I/O environment. As anyone who depends on medium in response to a corresponding request message, 

computerized systems to accurately and efficiently perform Tbe reply descriptor comprises at least one indication field 

selected tasks will readily understand: It is imperative that 5 tbal can function as a 'flag 1 to identify type of tbe reply 

valuable I/O messaging data be communicated in a reliable, descriptor, and a content field; whereby a reply message is 

efficient manner that reduces system I/O overhead by using generated only if at feast one predefined condition is not met 

less system resources such as system memory, CPU and the content field will, accordingly, comprise information 

(computer processing unit) cycles, system bus resources, of that reply message's storage location. Also characterized 

and so on. 10 is a method of responding over an I/O message passing 

ctttuk/adv HF top TMVPNTTfiN medium, to a request message. The method comprises tbe 

SUMMARY OF THE INVENTION sleps o£ ' gcwra ting a reply message to the request message 

It is a primary object of this invention to provide a melhod ojfl % at Jetst one predefined condition is not met; gener- 

of responding over an I/O message passing medium, to a 4lmg a descriptor having at least one indication field 

request message and to provide an associated reply descrip- J5 and a c^nt field; whereby the content field comprises 

tor for transmission over an I/O message passing medium in information of the reply message's storage location if it is so 

response to a corresponding request message. A reply mes- generated. 

sage need only be generated if at least one predefined Further characterized is a computer executable program 

condition is not met, the reply descriptor to include at least on a c^mer readable storage medium. Tbe program 

one indication field that identifies its type and a content field, M code compr ises: a first program sub-code for generating a 

whereby the content field comprises information of the reply Kply me ssage to a corresponding I/O request message only 

message's storage location (in the event so generated). It is tf M leasl one predefined condition is cot met. The first 

a further object to provide computer executable program program sub-code comprising instructions for generating a 

code on a computer readable storage medium, having rep | v descriptor having at least one indication field and a 

instructions for carrying out the novel method and generat- ^ ootaaii field that comprises information of the reply mes- 

ing the novel reply descriptor. sage's storage location if said reply message is so generated. 

The simple, efficient design of the invention allows the Th e content field to comprise data copied from the I/O 

innovative method, reply descriptor, and program code as request message if each predefined condition is met. 

contemplated hereby, to be tailored-to, readily installed, and Additional, further distinguishing associated features of 
run using currently-available processors, memory, commu- ^ ^ e reply descriptor, method, and program code of the 

nications protocol and interface types, as well as those invention wiH be readily appreciated as set forth herein, 

under, or contemplated for, development. Farther, unlike the including the following novel features. The message passing 

conventions currently specified and in use, the unique medium over which reply descriptors may be transmitted 

method, reply descriptor, and program code of the invention mav comprise one or more parallel, serial, and wireless bus, 

do not require that full reply message(s) be built, copied, 35 or m y hybrid thereof. More-specifically, suitable buses 

read and processed for each and every request message include those operational with any of a variety of hardware 

processed. In the spirit of this unique design, a reply interface types such as SCSI (Small Computer System 

descriptor can be generated and then transmitted for a Interface), Fibre Channel, PCI (Peripheral Component 

corresponding request for any class of messages as wDl be Interconnect), PCI-X, ISA (Industry Standard Architecture), 

further appreciated. 40 InfiniBand, IDE (Integrated Drive Electronics), USB 

Although tbe advantages of providing the flexible new (Universal Serial Bus), RS-232, EISA (Extended ISA), 

method, associated new reply descriptor, and program code, Local Bus, Micro Channel, and so on. Further, tbe message 

as described herein, will be more-fully appreciated in con- passing medium can utilize any number of communications 

oectioD with tbe fall specification, certain advantages are protocols such as those identified as SCSI, ATM 

listed as follows: 45 (Asynchronous Transfer Mode), IPI (Intelligent Peripheral 

(a) System Cost Reduction and Process Simplification — Interface), HiPPl (High Performance Parallel Interface), IP 
For the vast majority of request/commands generated (Internet Protocol), InfiniBand, SSA (Serial Storage 
by an initiator which are successfully completed Architecture), IEEE P1394, and so on. Upon the writing of 
(processed without error), a full reply message need not the reply descriptor to a reply-post buffer, an interrupt (or 
be build, copied, and read as is conventionally done; 50 any suitable alert mechanism by which to signal a host that 
thus, reducing adapter CPU firmware cycles necessary a reply descriptor has been so written) can be transmitted for 
to manage queues, which in turn, requires less expen- a host-based driver to read the reply descriptor; and once so 
sive adapters to handle the reply overhead. Unlike read, the host-based driver can correlate the reply descriptor 
conventional protocol, this powerful novel method and with the request message and send a notification message 00 
associated reply descriptor allows one to simplify the 55 to an originating-caller (such as a host-based operating 
process to communicate I/O request completion. Sim- system). 

plifying the design reduces overall system costs, such If each such predefined condition is met, the indication 

as the cost. Reducing system costs, in-turn reduces the field might farther comprise a type field, and the content 

cost to perform important I/O messaging functions. field can comprise data copied from and unique to the 

(b) Design Flexibility and Versatility— The invention can M request message as generated by a host-based driver; but if 
accommodate many different message passing medium the reply message is so generated, it preferably comprises 
hardware interface types; a wide variety of communi- data regarding the predefined conditions) not met The 
cations protocols and message templates; and a multi- content field might further have a receiving port identifier, 
tude of different types of I/O systems and devices. Also, especially in the event each such predefined condilioo 
Furthermore, many different computer platforms can 65 is met, tbe data unique to the request message can comprise 
readily use the more-flexible I/O reply solutions offered any f a number of identifiers such as: an address (whether 
by the instant invention. physical or virtual) to a storage space in a memory (which 
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could be a temporary-storage, e.g. a queue, or more- 
perraaoent storage, e.g. a message frame), an index value or 
offset lo a table, an index value or offset to a list, an index 
value or offset to a register, an index value r ofiset to a layer 
of hardware registers (stack), an index value or offset lo an 
array, content-data associated with a hardware assisted 
CAM, and so on. lb conserve computer resources, the alert 
signal may be transmitted to the host-based driver after a 
predetermined number of such reply descriptors have been 
generated. 

In the event the reply message is so generated, the content 
field of the reply descriptor can comprise an address to an 
available reply frame buffer located in a host memory; this 
address having been removed from a plurality of addresses 
residing on a reply-free buffer, each such address to identify 15 
a location of a corresponding reply frame buffer. Once the 
reply descriptor has been read by a faost-based driver, the 
host-based driver can be instructed to remove the reply 
descriptor from the reply-post buffer. 

BRIEF DESCRIPTION OF THE DRAWINGS 
For purposes of illustrating the flexibility of design and 
versatility of the innovative preferred method, associated 
reply descriptor, and program code, the invention will be 
more particularly described by referencing the accompany- 25 
ing drawings of embodiments of the invention (in which like 
numerals designate like parts). The figures have been 
included to communicate the matures of the invention by 
way of example, only, and are in no way intended to unduly 
limit the disclosure hereof. 

FIG. 1 is a schematic depicting a conventional split driver 
model 10 as explained in the "Intelligent I/O Architecture 



FIGS. 8A and SB depict alternative request and reply 
message formats for, respectively, a SCSI I/O Request 
Message and a SCSI I/O Error Reply Message. 

DETAILED DESCRIPTION OF THE 
5 PREFERRED EMBODIMENTS 

Two basic types of preferred reply descriptors of the 
invention are depicted in FIGS* 3A and 3B. Turn, first, to the 
Address Reply Descriptor 30 shown in FIG. 3 A: It includes 
10 information 34 useful for identifying a storage location of 
the frame for a reply message generated in connection with 
an unsuccessful I/O and an address bit 32. 
Description of Fields Represented in the Address Reply 
Descriptor of FIG.3A 



20 



PhysicalAddress BHi 3r3J of the pfaysual uddrtas of the reply message 
fhme generated, for example by the I/O Controller. 
This is • SMFA (System Metsigc Frame Address) 
thai has been shifted tight by 
one bit making room for the address bit 31 
A The address bU 32 la set to 1 to denote it is an 

Address Reply Descriptor (since u least 
one corairsutoVeoiidtttoa wis not met, 
there tore uosocccssEq] I/O). 



Specification" Version 2.0 (I a O Specification). An 
OS-specific module (identified as "OSM" at 12) that pro- 
vides an interface to an operating system ("OS") and a 
hardware device module (identified as "HDM" at 14) that 
provides an interface to each I/O adapter and corresponding 
device, which intercommunicate via a logical ~ 
layer" 16. 



FIG. 3B depicts another general type of reply descriptor, 
namely, a context reply descriptor 35 that includes data 
preferably comprising at least some portion or sub-portion 
of data copied from the corresponding request me ssa g e to 
30 which descriptor 35 pertains. For reference, the field con- 
taining this data copied from the request message is labeled 
"Protocol Dependent" 38a As will be better appreciated in 
connection with FIGS. 4 and 5, the context reply descriptor 
mechanism is unique, especially in that no reply message 
35 need accompany it in responding to an I/O request Use 
fields labeled 32 and 37a collectively mate up an indication 
field 36a encoded for an initial 'quick' identification of 
whether or not the descriptor is an address reply descriptor 
containing a pointer, or address, to a reply message (address 



FIGS. 2A and 2B (reproduced foam the l^O Specification 40 bit set to 1); and if the descriptor is not of an address type, 



for easy reference) schematically outline the relationship 
between conventional components of an I^O segment (a host 
platform 20, an IOP1 at 22, and IOP2 at 24). 

FIG. 3A is a schematic of the fields in a preferred general 
address reply descriptor of the invention. 

FIG. 3B is a schematic of the fields in a preferred general 
context reply descriptor of the invention. 

FIGS. 3C and 3D are schematics of the fields in two 
special cases of a preferred context reply descriptor of the 
invention. 

FIG, 3£ depicts the fields of an example "header" for a 
message. 

FIG. 3F depicts an example default reply message such as 
can be used to communicate certain selected details of any 
one or more predefined condition not met 

FIGS. 4 and 5 are schematics detailing selected message 
and data flow features of an I/O system designed to aid in 
carrying out a preferred method of the invention, including 
flow of a preferred reply descriptor of the invention. 

FIG. 6 depicts an example map of System Interface 
Registers through which a host can communicate with an 
IOC (I/O Controller)— preferably access to these registers is 
provided via memory and/or 10 mapping. 

FIGS. 

specifically detailing fields of an example Con fig Request 
Message and associated Config Reply Message. 



45 



the specific type of context reply descriptor it is (for 
example, see Type Table below). 

Description of Fields Represented in the General Context 
Reply Descriptor of FIG. 3B 



Typ«> 
Bits: 



The specific type of Context reply message, 
— Definition of Type bits fjiype Tabic): 



50 Bill Bit 0 Type 



55 



0 


0 


SCSI Initiator mode Context Reply 


D 


3 


SCSI Ttarget mode Context Reply 


1 


0 


Reserved 


1 


3 


Reserved 


A 




The Address biV-wken tsung • Context reply msg. this bit 






is reset to 0 (since Ihcic was successful 






completion of the I/O request). 



When tbe IOC is a SCSI initiator, a context reply descrip- 
60 tor such as that in FIG. 3C may be used for replying to an 
I/O request message that has been processed without error. 
The receipt of the reply descriptor 40 as depicted, namely a 
SCSI Context Reply, by the host driver implies tbe success- 
ful completion of the I/O. In this example, (he 10 C has 
7 A and 7B depict alternative message formats, 65 copied (digitally, or omerwise, duplicated) the MessageCon- 

text data directly from a corresponding request message to 
generate a content field (386) for the reply descriptor 40 
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wbich is put on a Reply Post buffer (such as either of the 
FIFO's sbowD in FIG. 4 at 77 and 87). The Type (37b) and 
A (32) sub-fields of indication field 36b, are set once the 
MessageComext of the request message has been copied. In 
this example as shown, bits 0::28 of the MessageComext can 
be used by the host driver in any particular way selected. 
Description of Fields Represented in the SCSI Initiator 
Context Reply Descriptor of FIG. 3C 



10 



•continued 



•type Specifies type or mode of this Context 

reply CKflugc. 

A The Address bit, here it has been reset to 0 (since 

there vu successful completion of the I/O request}. 
R Reserved bit 



10 



MessageContexl A copy of the McssagcConlext field, tils 0:28, copied 

tram ihBt supplied by the boil in the request message. 
Type The specific type of Conical Reply-Set to denote * 

SCSI initiator mode Context Reply. 
A The Address bit, reset to 0 (since there was successful 

completion of tbc VO request as in the case for general 

Context Reply 35). 



15 



As mentioned above, two types of messages are used to 
convey information within the I/O method and system of the 
invention: (1) request messages are created by the system to 
"request" an action by an IOC; and (2) reply messages are 
used by an IOC to send status information back to the 
system. Each message includes a message header (of any 
predefined size) and a paylo&d. By way of example only, the 
message header 50 represented in FIG. 3£ is the first 12 
bytes of each message frame and reserved and unused fields 
will have a value of 0 (zero). Hie header includes informa- 



Description of Fields Represented in the Message Header of 
FIG.3E 



The alternative reply descriptor 45 illustrated in FIG. 3D t # a 

has more detailed information concerning origination and 20 lion to uniquely identify the message, 
transmission of the corresponding request The specific 
information selected foe encoding in a context reply descrip- 
tor of the invention will depend upon, among other things, 
I/O architecture design factors. When the IOC is in TAR- 
GET" mode and a SCSI command has been transmitted and 
received, the depicted SCSI Target Context Reply Descrip- 
tor 45 may be used to convey moxe specific information to 
the host system. Here, indication field 36c is comprised of 
fields labeled Type (37c) and A (32) aod the protocol 
dependent content field 38c includes valuable additional 
information as follows: 

Description of Fields Represented in the SCSI Target Con- 
text Reply Descriptor of FIG. 3D 



Function 
Dependent 
Reserved 
Function 



30 



MessageFlags 
MeasageContext 



35 



The format of this Held is dependent on the function 
being described. 
Function dependent. 

Tbe function number of this message. This number 
detennines the format of tbe rest of the message 
(and differentiates end) 
request message from tbe others). 
AO reserved bits mast have a selected value, such as 0, 
unless otherwise identified in specific messages. 
A value used to uniquely identify this message. 
Created by the host driver and not modified by the 
IOC This value can be copied and 
'returned* In the Con text Reply, see FIG. 3B at 38b. 



Hoctlndoc (43) 
lOdndex (42) 



biitiiiorlndex (41) 



This index is specified by the host to track the t/O. 
The index used by the IOC to track this I/O, This bit 
can be used to indicate on which port the initial 
commend was received. 

A 6-bit value Indicating which Initiator sent this 
command. For parallel SCSI systems this can be 
the actual Initiator ED value. For FCP systems, 
U's as index into t table of logged in Initiators. 



I/O reply messages are currently used in each instance a 
response to an I/O request is transmitted back to an OSM 
40 (operating system module). The table below describes a 
default reply message such as thai labeled 60 in FIG. 3R 
Description of Fields Represented in the Default Reply 
Message of PIG. 3F 



IOCStatns 



IOCSTXrUS_SUOCESS 

I(X^OTJSuJNVALID_PUNCnON 

IOCSDSTUS_BUSY 

ICX^rDffUS_rNVAlJD_SOL 

!CK^riXrOS_MsG_XFEJUERROR 

lOC5TXrUS_DArA_XFER,_ERROR 

IOCSTXrUS_INSUFFIOEyr_RESOtmCES 

IOC^DOt3S_IWAUD_J»IELD 

IOCSTATOSu_CONFIGJAD_ACnON 

iOCSTMTUS_CONFIG_BAD_TYPE 

IOCSEATUS_QONFIGJAD_PAOE 

IOCST>TUS_CONHOJAD_DATA 

lOCSTArUS_COKFIG_NO_DEFAUlTS 

iocsrnmjs_ooNFiG_CANT_coMMrr 

10CSTCnJS_SCSI__RECOVERED_ERROR 
IOCSTMVS.SCSIJNVAUDJUS 
ICK^TftTUS^CSLlWAUDJAROfmP 
IOCSTXrUS.SCSI_DEVICE_NOT_THERE 



Description 

Command completed successfully from the ICC 
standpoint. 

Function not supported by the IOC 

Con not process tbe request si this time 

SOB not supported or understood. 

System bus error detected during message trensL 

System bus error detected during data transfer. 

The IOC has uunfficienl resources to process the 

request at this time. 

A field in the message ban an invalid value 
lite action tt not supported 
The configuration type ii not supported 
The configuration page Is not supported 
Incorrect Add setting within the conftgnntfan data 
Can not set defaults for this page 
Non-volatile memory not available or error while 
writing persistent data to non-volatile memory 
VO operation completed successfully after retries 
Out of range Bos value in request message 
Out of range Targe tlD value in request message 
Selection tune-out or device does not esdst 



07/31/2003, EAST Version: 1.04.0000 



US 6,591,310 Bl 

11 

-continued 



TOCStalus 

IOCSTATUS-SCSL-OAW^OVERRON 

rOCSTATUS_SCSl_DATA_UNDERaUK 

lOCSTATUS^SCSUO^DATA-ERROR 

IOC^ATUS_^UPROTOCOL_ERROR 

IOCSTAnJS_$CSI_lASK l— TERMINATED 

IOCSTATUS_SCSL-BUS_RESBr 

IOCSTATUS_SCSL_TXSK_MG\1T_FAaED 
IOCSrATUS_TAKOET_PRIORlTY_IO 

I(XOTAnB - jAXOET_INVAliD_POKr 

I(X3I>majrA3^ET_lNVAliD_I0CINDEX 

lOCSTArUS_TARGET_ABORTED 

IOCSrArUS_TAROET_NO_OONNECnON_ 
BETECVABLE 

IOCSTAnJS_TAXGET_W_CONNECnON 

lOCSTtiflTlJS_TAROET_FC_ABOBTED 

IOCSTXTUS _TAJIGET_JNVAUD_DID 

IOCSWl^_WGET_FC_hK)DEJLOGGE 
D_OUT 

lOCLoglnfo Should be logged hy die host drive*. 



Dot crip lion 

SCSI device attempted to transfer more data than 

the amount specified by the byte count 

SCSI device transferred less data than the amount 

specified by the byte count 

I/O terminated because of unrecoverable bus 

parity or CRC error 

I/O terminated because of unrecoverable bus 
protocol error 

I/O terminated because of SCSI Task 
Management Request 

I/O terminated because of a Bus Reset unrelated 

to a SCSI Task Management Request 

SCSI Task Management function foiled 

An I/O operation has been received that require* 

priority handling 

A command was directed to a port that does not 
exist on this IOC 

The Target Host used an Iodndex value that is 

invalid or not to use on the IOC. 

This ta a reply for an VO or buffer that was 

aborted at the request of the host 

Unable to communicate to the Initiator of this I/O. 

The host can retry this operation later. 

Unable to communicate to the Initiator of this I/O. 

This I/O can never be conrimmrl 

This Is a reply for an operation or buffer thai was 

aborted at the request of the host 

The Target Host attempted to send a request that 

InrUrf*- 1 a D__ID value that is not in use. 

This operation has been canceled because the 

destination node has logged us out 



One can readily appreciate the many and various types through space from a transmitter to a receiver; or some 

kinds of events which could trigger the building of a reply combination thereof) whether local or physically remote, 

message according to the method and program code of the 35 For each data element, mere can be many fields in the 

invention. An address reply descriptor such as that depicted database that hold the data items. As basic units of storage, 

at 30 in FIG. 3A, is accordingly generated in order to locate a data element describes the logical unit of data (i.e., the 

the reply message to which it points. It is only when al least logical definition of the field), fields are the physical storage 

one condition is not met, indicating that the request was not units (typically one or more bytes in size), and data items are 

processed without error, that such a reply message is gen- 40 the mddvidual instances of the data elements (i.e., actual data 

erated for transmission over the I/O message passing stored in the field)* Computer readable storage medium/ 

medium. For example, occurrence of one or more of the media, as used herein, can be any data carrier or recording 

following events, among others, could trigger the generation medium into, or onto, which information (such as data) can 

of a reply message: execution of any one command of the be read and copied, such as magnetic (diskettes, hard disks, 

request is not completed initially or after a selected number 45 Iomega Corporation's ZIP ™/J AX™ /Click!™ disks, tapes, 

of * retrys', any one command of the request was made at an drums, core, thin-film, etc.), optic (CD-ROM, CD-E, CD-R, 

improper time, an allotted time for execution of any one CD-RW, DVD, and other devices whereby readout is with a 

command of the request was exceeded, unsuccessful data light-source and pbotodetector), magneto-optic media 

transfer of any portion of the request message, quantity of (media for which optical properties can be changed by an 

data transferred exceed&d byte count specifications, quantity so applied magnetic fieloV-used in high end drives), and other 

of data transferred was less-than that required in byte count sucb devices. 

specifications, processor resources were insufficient to A stack is a set of hardware registers or a reserved amount 
execute any one command of the request, at least one field of memory used for arithmetic calculations, keep track of 
of the request message included invalid data, at least one internal operations, etc. A CAM (Content Addressable 
value from the request message was out of range, data 55 Memory), also referred to as "associative storage", is storage 
transferred was insufficient to execute any command of the that can be accessed by comparing the content of the data 
request, hardware interface of the message passing medium stored in it rather than by addressing predetermined 1 oca- 
was incompatible with the target device, communications tions. A buffer is any reserved segment of memory or 
protocol utilized by the message passing medium was accessible storage used to hold data during processing. A 
incompatible with the target device, an unrecoverable bus 60 host can be any computer or computerized device that acts 
parity error has occurred, a task management function has as a source of information or signals, including for example, 
failed, a host processor aborted the request message, a target a centralized mainframe that is a 'host' to its terminals, a 
device node has logged-off, and so on. server that is 'host 1 to its clients, to a desktop PC that is 
The following is provided by way of reference: A message 'host' to its peripherals, and in network architectures, a client 
is any sized set or subset of data generated for transmission 65 station that is a source of information to the network, 
over a communications/message passing medium (which As mentioned above, the message passing medium over 
can comprise cabling, alone, or can include transmission which reply descriptors may be transmitted may comprise 
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one or mote parallel, serial, and wireless buses, r any 
hybrid thereof. More-specifically, suitable buses include 
those operational with a variety of hardware interface types 
such as those identified as SCSI; Fibre Channel; PCI 
(Peripheral Component Interconnect— commonly used to 
provide a high-speed data path between the CPU and 
peripheral devices such as video, disk, network, etc.); PCI- . 
X; ISA (Industry Standard Architecture — an expansion bus 
commonly used in PCs along with ISA buses); InfiniBand; 
IDE (Integrated Drive Electronics — widely used to connect 
hard disks, CD-ROMs and tape drives to a PQ; RS-232 
(Recommended Standard -232 — an 7IA/EIA standard for 
serial transmission between computers and peripheral 
devices such as modem, mouse, etc., that uses a 25 -pin 
DB-25 or 9-pin DB-9 connector); USB (Universal Serial 
Bus — used for low-speed peripherals such as the keyboard, 
mouse, joystick, scanner, printer and telephony devices); 
EISA (Extended ISA); Local Bus; Micro Channel; and so 
on. 

The message passing medium can utilize any of a wide 20 
variety of suitable communications protocol such as SCSI; 
ATM (Asynchronous Transfer Mode — a network technol- 
ogy for both LANs, local area networks, and WANs, wide 
area networks); IPI (Intelligent Peripheral Interface-a high- 
speed bard disk interface used with minicomputers and 25 
mainframes that transfers data in the 10 to 25 MBytes/sec 
range); HiPPI (High Performance Parallel Interface — an 
ANSI-standard high-speed communications channel that 
uses a 32-bit or 64-bit cable and transmits at 100 or 200 
Mbytes/sec); IP (Internet Protocol-the IP part of the TCP/IP 
communications protocol); InfiniBand, SSA (Serial Storage 
Architecture); IEEE P1394 (sometimes referred to as 
"FiieWire" — high-speed serial bus communications that 
allows for the connection of up to 63 devices); and so on. 

One can better appreciate the flexibility of the reply 
descriptor and message flow of the invention in connection 
with viewing FIG. 4 which, by way of example only, 
includes the novel intercommunication of two separate host 
drivers represented and labeled as #1 at 70 and #2 at 80. The 
transmission of information in the form of request and reply 40 
descriptors as well as request and reply messages throughout 
the I/O system represented can be accomplished through the 
use of, for example, a dual function in PCI (the logical 
separation of which is indicated by dashed line 85) and 
multiple service connections in InfiniBand. Steps detailing 
activity within a novel I/O system that can carry out a 
preferred method of the invention are summarized below in 
connection with corresponding data flow lines (labeled A 
through L in FIG. 4): 

A* Each host driver 70, 80 initially receives an I/O request 
from an operating system (not shown, for simplicity). 

B. Each host driver allocates a system message frame (SMF) 
from a collection of frames such as those shown at 71 and 
81 which preferably resides in system/host memory, and 
builds an I/O request message within the SMF, Since, 
here, SMFs reside in host memory, the particular means 
by which allocation is carried out is the responsibility of 
the host driver, and can be one of any conventional SMF 
allocation method. 

C. Each host driver 70, 80 generates its own request message 
frame descriptor (represented at 73, 83) for each respec- 
tive I/O request message built by the host. 

D. Each host driver writes its respective request message 
frame descriptor 73, 63 to a request queue labeled Request 
Post FIFO at 75 (in this novel example, the Request Post 
FIFO 75 manages request message frame descriptors from 
both host drivers 70, 80). At this point the IOC 



(represented at 90) takes ownership/control of the SMF 
within which each respective I/O request message resides. 
E. The IOC 90 reads the request message frame descriptors 
from the Request Post FIFO 75 and DMA's (Direct 
Memory Access — whereby data is transferred from 
memory to memory without using the CPU) the request 
messages to a local message frame (here, 'local' to the 

loq, 

xo F. The IOC 90 generates and sends the appropriate request 
messages to a target device based on the port type 
associated with the Bus and TargetlD fields of the request 
message. For an example of an l 2 0 request message 
structure which can be accommodated according to the 
invention — see I 3 0 Specification, section 3.4.1.2.1. 

G. The IOC 90 receives the reply information from the target 
device— concerning whether the original request was 
processed without error, and if not, an indication of which 
condition was not met (the latter generally only to occur 
in a small fraction of the cases, such as for example, if a 
driver or interconnection is faulty). 

H. If the I/O status is successful (request was processed 
without error) the IOC 90 writes data unique to the 
corresponding original request message, such as the Mes- 
sageContext field value (see FIG. 3C at 38b) or other 
Protocol Dependent data (see FIG. 3B at 38a and FIG. 3D 
at 38c) to the respective reply queue (labeled 77, 87 Reply 
Post FIFO), in turn, causing an alert signal to be trans- 
mitted (e.g., a system interrupt is generated) letting the 
respective host driver 70, 80 know that a reply descriptor 
is in the Reply Post buffer 77, 87. At mis point, the 
respective system/host driver (represented at 70, 80) 
regains ownership/control of the SMF within which each 
respective I/O request message resides. 

I. If the I/O status is not successful (e.g., either the I/O 
request was not folly processed or it was processed but 
done so with an error, thus, the I/O request was not 
successfully completed), the IOC 90 removes an address- 
to an available reply message frame from the reply queue 
(labeled 78, 88 Reply Free FIFO). The IOC 90 then 
generates a reply message in the host based message 
frame and writes the physical address of the reply mes- 
sage frame, shifted to the appropriate bits, to the respec- 
tive reply queue (labeled 77, 87 Reply Post FIFO), in turn, 
causing a signal to be transmitted (e.g., a system interrupt 
is generated) informing the respective host driver 70, 80 
that a reply descriptor is in the Reply Post buffer 77, 87. 
At this point, the respective system/host driver* 
(represented at 70, 80) regains ownership/control of the 
SMF within which each respective I/O request message 
resides. 

J. The system/host driver 70, 80 receives the respective 
interrupt (or other suitable signal) and reads the Reply 
Post FIFO buffer 77, 87 to get the content field 
(comprising data such as the MessageCbntexl field value, 
see FIG. 3C at 38£, some other Protocol Dependent data, 
see FIG. 3B at 38a and FIG. 3D at 38c, or a 
FhysicalAddress, see FIG. 3A at 34, to the host-based 
reply message frame generated under step I. above). If 
there are no posted reply descriptors when the system/host 
driver 70, 80 reads a respective Reply Post FIFO 77, 87, 
the host driver 70, 80 will receive some arbitrary value 
(such as the value FFFFFFFFb) indicating that there are 
no more reply descriptors to be read. 
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K. Each respective host driver 70, 80 then responds to the 
initiator/caller (such as an operating system, not shown 
for simplicity) appropriately. 

L. In the event a reply frame (72, 82) was needed during the 
process to respond to the initial I/O request (which 5 
generally occurs only in a very small fraction of the cases) 
and, thus, an available address was removed from the 
Reply Free buffer (78, 88) and a reply message generated 
and written to the allocated reply fame, the host driver 
(70, 80) returns the address to the respective Reply Free 1Q 
FIFO buffer 78, 88. 

Referring back once more to FIGS. 3A and 3B to sum- 
marize the features depicted by FIO. 4: The Address Reply 
mechanism (such as that explained above as step I. where 
the I/O status is not successful) requires an IOC 90 to 15 
remove an available SMF address from the Reply Free 
buffer (FIG. 4 at 78 or 88), build a reply message, DMA the 
reply message to the respective host driver 70, 80, as well as 
build a reply descriptor (FIG. 3A at 30) and place it on a 
respective Reply Post buffer (FIG. 4 at 77, 87). On the other 2Q 
hand, the much more efficient context reply mechanism of 
the invention (explained above as step H. where the I/O 
status is successful) reduces these PCI accesses, thus 
increasing performance, to a single write of a reply descrip- 
tor (such as any of those depicted in FIGS. 3B, 3C, and 3D ^ 
at 35, 40, and 45) to the Reply Post buffer (FIG. 4 at 77, 87). 
This is accomplished by having the IOC write a single 
content field (of any designated length) shifted the appro- 
priate bits to accommodate an indication field (that can 
function to identify the general type of reply descriptor, see 3Q 
FIGS. 3B, 3C, and 3D at 36a, 366, and 36c) to a Reply Post 
buffer (FIG. 4 at 77, 87). See also, the data flow diagram 
labeled FIG. 5. 

Therefore, as one can readily appreciate that the novel 
context reply mechanism of the invention requires that a 3S 
host driver do only a single PCI Read to retrieve the context 
and indication fields (such as are referenced at 38a-38c and 
36o-36c of reply descriptors 35, 40, 45, respectively) from 
a Reply Post buffer, and no PCI Write to post the Reply Free 
SMF address is needed in the majority of instances where no ^ 
reply message frame is used when the I/O status is success- 
ful. Note that the figures label several queues specifically as 
FIFO (flrst-in-firsl-out), although they need not be that 
particular type of buffer. 

Turning to the data flow diagram labeled FIG. 5, identified 45 
(for reference only) abng the left hand side (see arrow 120) 
are blocks representing the various logically defined layers 
of an I/O system execution environment. Details of the I/O 
system data flow represented in FIG. 5 are set forth below 
in connection with reference numbers: J0 

101. An initiator/caller Operating System (OS) issues a 
request or command. 

102. An OSM (operating system module, or OS Specific 
Device Driver) — such as the two modules referenced in 
FIG. 4 as host drivers 70, 80 — accepts the request and 55 
translates it into a request message addressed to a target 
DDM. The OSM has the option to place a pointer 
(location indicator, such as a physical or virtual 
address) to the OS I/O request in the request message's 
TransaclionContext field. 60 

103. The OSM (system/host driver e.g., the host drivers at 
70, 80 in FIG. 4) invokes the communication layer to 
deliver the request message. 

104. The host driver queues the request message (can be 
done via mechanism such as thai identified in I a O 6$ 
Specification as Messengerlnstance) by copying it into 

a message frame buffer residing on an IOC. 
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105. The IOC posts the request message to the target 
DDM's event queue. 

106. The target DDM processes (or, at least attempts to 
process) the request 

107. After the target DDM processes and satisfies the 
request successfully (which occurs for the vast majority 
of request messages transmitted), the IOC generates a 
reply descriptor for that request. Note here that, 
although not specifically illustrated in FIG. 5, for the 
small percentage of request messages that are not 
'processed without error' an available reply message 
frame address is removed from available message 
frame addresses residing in a buffer (e.g., Reply Free 
buffer at 78 or 88 in FIG. 4), a reply message is built 
by the IOC to include information concerning the fault, 
error, failure, etc., (i.c, that which has not been met) 
and copied into the reply message frame. The IOC then 
generates a reply descriptor (with an address, or 
whereabouts, of the reply message frame, with bits 
shifted to accommodate an indication field). 

108. The reply descriptor generated (whether it be an 
Address Reply or the more often encountered Context 
Reply, see FIGS. 3A-3D) is queued to a Reply Post 
buffer (such as those shown in FIG. 4 at 77, 87). 

10°. The writing of the reply descriptor to a Reply Post 
buffer can be done in connection with some type of an 
alert signal, eg., a system interrupt, 10 the system/host 
driver thai a reply descriptor is ready for reading. The 
system driver receives the alert signal and reads the 
Reply Post buffer to get the reply descriptor informa- 
tion. Due to indication field 32 of the reply descriptor 
(see examples in FIGS. 3A-3D), it is readily apparent 
whether the descriptor is of an Address or Context reply 
type. If the descriptor is of the Address type, the 
associated reply message must be found and read. 

110. The system/host driver then correlates each specific 
reply response with an original, corresponding request 
to complete the response process. For example, the host 
driver can retrieve an address-pointer to the original I/O 
request by looking at a Context reply descriptor's 
context field (see 38a, 386, 38c in FIGS. 3B-3D) or 
looking at an I/O request identifier found in any reply 
message, if it was necessary to so generate a reply 
message (see FIG. 88 for as example format). 

111 . The host driver returns the I/O request to the initiator 
operating system. 

Since a host system generally commumcates with an IOC 
through the use of System Interface registers, by way of 
example only, FIG. 6 illustrates an example System Inter- 
face Register Map 130 for this purpose. Access to registers 
can be provided as is customary in I/O architecture, via 
memory and/or I/O mapping. 

FIG. 7A illustrates yet another example of a request 
message format, namely a Config request message 140, for 
supporting configuration operations such as read/write. The 
format of an example reply message to the FIG. 7A request, 
is represented at 150 in FIG. 7B. The Config request 
message 140, such as that in FIG. 7A, is used to access 
operational parameters supported by the IOC 
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Description of Fields Represented in the Example Config 
Reply Message of FIG. 7B 



ICCStatus 


This field is used to return IOC supplied information fpcdBc to 




Configuration requests to addition to the fuoction independent 




values specified as shown to lie Default Reply Message. 


tOCStatus 


Description 



lOCSTArUS-CONEIOJAD^ACnON 

IOCSTATUS_OOKFIO_BAD_TyPE 

IOCSTATOS L .COKFIG_MD_PAOE 

rOCSTArUS_COKFlG_BAD_DATA 

IOCSTATUS_CONF1G_NO_DEFAULTS 

IOGSTATUS^ONnO_CANr_OOMMrr 

Rawed 



Tbe actloa ts Dot supported 

lite configuration type is not sopporled 

The coafiguratkra page is not supported 

Incurred field setting within the configuration data 

Gas sot set defaults for this page 

Non-vobUilc memory not available or error while 

writing peniilent data to non-volatile memory 

Function spe ci fi c finlrin. 



FIGS. BA &nd SB depict an alternative SCSI request 
message format labeled 160 and corresponding error reply 
message formal 170: SCSI Initiator 10 message represented 
in FIG. 8A is used to send a specific class of requests, 
namely, SCSI I/O requests to specific target devices. And 
according to the novel features of the invention, the SCSI IO 
Error reply message 170 in FIG. 8B need only be generated 



-continued 

SQL He scatter gather list which irimitirVa the memory 

location of the dita for this 10. 

Description of Additional Fields Represented in the FIG. 8B 
Example Error Reply Message 



ICCLoglnfb 
IOCStatas 



An unpkmeitfatioQ specific value intended to supplement the IO 
Controller status. 

This field is used to retain IOC supplied information specific to 
SCSI IQ request! in addition to the function independent values 
specified in FIG. 3P Default Reply 1 



roCStatus examples 



Description 



IOCSI>STUS_SCSLJIECOVERED_ERROR 

IC<STOTJSJCSI_INVAUD_BUS 

lOCSnCOTS^CSI_JrmiiD_TARGETn> 

IOCSIAr^JSCSLJ>EVlCS-JWjrHERB 

IOCSTVOTS_5CSCJW3A_OVERRUN 

IC<SIAIUS^CSLJ>A1A^UNDERRUN 

IOCSrATUS_SCSL_IO_DATA_ERROR 

ICKSIvmJS^CSI^ROrrOCOlwERROR 

ICCSIXI\JS^CSUTASK_TERMINATED 

IOCSTATOS_£CSrjUS_JlESEr 

IC<^rATTJS^CSt_TASIC^>IGMT_FAlLED 
Reserved 



I/O operation completed successfully after retries 

Out of range Bos value in request message 

Oat of range large UD value is request message 

SfTtrtifTj time-out or device does not exist 

SCSI device attempted to transfer more data than 

the amount specified by the byte curat 

SCSI device transferred fess data than the amount 

■peemed by the byte count 

I/O terminated because of unrecoverable bus parity 

CRC erjoT 

I/O terminated because of unrecoverable bos 
protocol error 

I/O trrmifl^M ^ S^Sl T>*V M»nwg^jnr.»l 

Request 

I/O terminated because of a Bus Reset unrelated to 
a SCSI Task Management Request 
SCSI Task Management fraction Hailed 
Functioo depcaccnl fields. 



and transmitted if the SCSI IO request experiences any of a 
number of errors or failures during the process to carry it out 
(e.g., an event occurs such thai any one of a set of predefined 
conditions is not met) and the IO request is, therefore, not 
completed. 

Description of Fields Represented in the Example SCSI IO 
Request Message of FIG. 8A 



Target ID The target device identification number. 

Bui The SCSI bus number that the target device exists on. 

CDBXength Number of used bytes in CDB field. 

MessagcFlags All reserved bits must have a value of OL 

LUK The Logical Unit Number of the target device. 

CDB SCSI Command Descriptor Block. 



While certain representative embodiments and details 
have been shown merely for the purpose of illustrating the 
invention, those skilled in the art will readily appreciate that 
various modifications may be made without departing from 
the novel teachings or scope of this invention. Accordingly, 
all such modifications are intended to be included within the 
scope of this invention as defined in the following claims. 
Although the commonly employed preamble phrase "com- 
prising the steps or may be used herein, or hereafter, in a 
method claim, the Applicants in no way intends to invoke 35 
U5.C section 112 f 6. Furthermore, in any claim that is filed 
hereafter, any means-plus-function clauses used, or later 
found to be present, are intended to cover the structures 
described herein as performing the recited function and not 
only structural equivalents but also equivalent structures. 
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What is claimed is: 

1. A reply descriptor for transmission over an I/O message 
passing medium in response lo a corresponding request 
message, comprising; 

at least one indication field that identifies type of the reply 

descriptor, and a content field; and 
whereby a reply message is generated only if at least one 

predefined condition is not met and said content field 

comprises information of said reply message's storage 

location, if so generated. 

2. The reply descriptor of claim 1 wherein: 
the message passing medium comprises a bus operational 

with a hardware interface type selected from toe group 
consisting of SCSI (Small Computer System Interface), 
Fibre Channel, PCI (Peripheral Component 
Interconnect), PCI-X, ISA (Industry Standard 
Architecture), InfiniBand, IDE (Integrated Drive 
Electronics), USB (Universal Serial Bus), RS-232, 
EISA (Extended ISA), Local Bus, and Micro Channel; 
and 

the message passing medium utilizes a communications 
protocol selected from the group consisting of SCSI, 
ATM (Asynchronous Transfer Mode), IPI (Intelligent 
Peripheral Interface), HiPPI (High Performance Paral- 
lel Interface), IP (Internet Protocol), InfiniBand, SSA 
(Serial Storage Architecture), and IEEE P1394. 

3. The reply descriptor of claim 1 wherein: upon the 
writing of the reply descriptor to a reply-post buffer, an 
interrupt is transmitted for a host-based driver to read the 
reply descriptor; and once so read, said host-based driver 
correlates the reply descriptor with the request message and 
sends a notification message to an originating-callcr. 

4. The reply descriptor of claim 1 wherein: 
said indication field comprises an address bit; 
if each said predefined condition is met, said indication 

field further comprises a type field, and said content 
field comprises data copied from and unique to the 
request message as generated by a host-based driver; 
but 

if said reply message is so generated, said reply message 
comprises data regarding said at least one predefined 
condition not met 

5. The reply descriptor of claim 4 wherein: 
if each said predefined condition is met, said content field 

further comprises a receiving port identifier, and said 
data unique to the request message comprises an iden- 
tifier selected from the group consisting of: an address 
to a storage space in a memory, an index value to a 
table, an index value to a list, an index value to a 
register, an index value to a stack, an index value to an 
array, and content-data associated with a hardware 
assisted CAM; and 
said reply-post buffer is a FIFO (First-In-First-Out) type 
buffer. 

6. A reply descriptor for transmission over an I/O message 
passing medium in response to a corresponding request 
message, comprising: 

at least one indication field comprising an address bit, and 60 
a content field; 

whereby a reply message is generated only if at least one 
predefined condition is not met and said content field 
comprises information of said reply message's storage 
location, if so generated; 

wherein each said predefined condition is met said indi- 
cation field further comprises a type field, said content 
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field comprises data copied from and unique to the 
request message as generated by a host-based driver, 
said data unique to the request message comprises a 
host-specified index value; 
an alert signal for said host-based driver is transmitted 
upon the writing of both the reply descriptor and a 
second reply descriptor to a reply-post buffer, said 
second reply descriptor comprising a second content 
field having second data copied from a second request 
message, and once said reply descriptors have been 
read by said host-based driver, said host-based driver 
correlates each said reply descriptor with a respective 
request message and notifies an originating-caller of 
completion of both of said request messages, 

7. The reply descriptor of claim 1 wherein: said at least 
one predefined condition is not met and said content field 
comprises said information, said information to comprise an 
address to an available reply frame buffer located in a host 
memory; and said address is one from a plurality of 
addresses, each of which identifies a location of a corre- 
sponding reply frame buffer. 

8. The reply descriptor of claim 7 wherein said at least one 
predefined condition is not met because execution of at least 
one command included in the request message was not 
completed, said corresponding reply frame buffers reside in 
said host memory, and said plurality of addresses resides on 
a reply-free FIFO buffer. 

9. The reply descriptor of claim 6 wherein: 
once said address to said available reply frame buffer is 

removed from said reply-free FIFO buffer, said reply 
message is generated by an I/O controller (IOC) and 
copied into said available reply frame buffer, and 
the reply descriptor is written to a reply-post buffer for a 
host-based driver to read. 

10. The reply descrqitor of claim 1 wherein: 
the request message comprises at least one command; and 
said at least one predefined condition is not met upon the 

occurrence of an event selected from the group con- 
sisting of: execution of said command is not completed, 
execution of said command is not completed after a 
retry, said command is made at an improper time, an 
allotted time for execution of said command is 
exceeded, unsuccessful data transfer of any portion of 
the request message, quantity of data transferred 
exceeds byte count specifications, quantity of data 
transferred is iess-than byte count specifications, pro- 
cessor resources are insufficient to execute said 
command, at least one field of the request message 
comprises invalid data, al least one value from the 
request message is out of range, any data transferred is 
insufficient to execute said command, hardware inter- 
nice of the message passing medium is incompatible 
with a target device, communications protocol utilized 
by the message passing medium is incompatible with a 
target device, an unrecoverable bus parity error has 
occurred, a task management function has failed, a host 
processor aborts the request message, and a target 
device node has logged-off , 
11. A method of responding over an I/O message passing 
medium, lo a request message, the method comprising the 
steps of: 

generating a reply message to the request message only if 

at least one predefined condition is not met; 
generating a reply descriptor having at least one indica- 
tion field that identifies type of said reply descriptor, 
and a content field; whereby said content field com- 
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prises information of said reply message's storage descriptor further comprises wiling said content field to a 

location if said reply message is so generated. reply-post buffer, said content field to further comprise a 

12. The method of claim 11 wherein: if each said pre- receiving port identifier and a request-initiator identifier; and 
defined condition is met, said content field to comprise data further comprising the step of transmitting a system interrupt 
copied from the request message rather than said storage 5 f or a host-based driver to read said reply descriptor, 
location information. 18. The method of claim 17 further comprising the steps 

13. The method of claim 12 wherein: 0 f ; reading said reply descriptor, correlating a request mes- 
the message passing medium comprises a bus operational sage identifier of said reply descriptor with the request 

with a hardware interface type selected from the group message; and notifying an originating-caller to confirm 
consisting of SCSI (Small Computer System Interface), *° completion of the request message. 
Fibre Channel, PCI (Peripheral Component 19. The method of cUim 17 wherein said step of gener- 
Interconnccl), PCI-X, ISA (Industry Standard amig ^ re pjy descriptor is performed with an I/O con- 
Architecture), InfiniBand, IDE (Integrated Drive toiler (IOQ; and said step of transmitting a system interrupt 
Electronics), USB (Universal Serial Bus), RS-232, fe ^^^^ with said IOQ and further comprising a reply 
EISA (Extended ISA), Local Bus, and Micro Channel; 35 queuc localcd m an ]OC memory, said register to 
wri comprise said reply-post buffer and a reply free buffer on 
the message passing medium utilizes a communications WD i c h a plurality of addresses, each of which identifies a 
protocol selected from the group consisting of SCSI, D f a corresponding reply frame buffer, reside. 
ATM (Asynchronous Transfer Mode), 1PI (Intelligent ^ 2Q ^ of daim 12 wherein said at least one 
Peripheral Interface), HiPPl (High Performance Paral- predefined condition is not met, and said step of generating 
lei Interface), IP (Internet Itatoco£ InfiniBand. SSA ^ d ^ xot ^ ^ 
(Senal Storage Arc^teotoe), and IEEE P1394. £ * ^ ^ ^ fie , d lQ 

14. The method of claim 12 wherein said mtoUon fieW ™ sJ^nnation an address to an avail- 
compnses an address bit, and further composing the steps ^ ^ ^ ^ * & ^ ^ 

0 ' . , „ , . , .j address having been taken from a reply-free on which a 

if „ch said p^fincd condiuon * met, generating said *Lm*** reside; aod forther comprising the 

indication field lo further comprise a type field and ' . . . ' . „„-,u „;j!nr..j 

Lerating said data copied to comprise data mrique to step of: generating said reply message wth satd IOC and 

to re^eft message; bSt ^ copymg said reply m<^ge mto saul available reply frame 

said al least one predefined condition is not met, £»* ""J*- r ^ on a computer 

atine said reply message to comprise data regarding . . , wum * JulVA ****** * & . . . _ 

r d at least one predefrrcd condidon not met readable storage medium, the program code comprising: 

15. The method of claim 14 further comprising the steps a first program sub-code for generating a reply message to 
Q £ 35 a corresponding I/O request message only if at least one 

upon the writing of said reply descriptor to a reply-post predefined condition is not met; and 

buffer, transmitting an alert signal for said host-based said first program sub-code comprising instructions for 

driver to read said reply descriptor, and generating a reply descriptor having at least one indi- 

once so read, correlating said reply descriptor with the cation field and a content field that comprises infbnna- 

request message and notifying an originating-caller of 40 tion of said reply message's storage location if said 

a completion results. reply message is so generated, but said content field to 

16. The method of claim 12 further comprising the steps comprise data copied from said I/O request message if 
of initially receiving an I/O request comprising at least one each said predefined condition is met 

command from an operating system, and generating the 22. The program code of claim 21 wherein said instruc- 

requesl message lo include said one command; and wherein 45 ^ oas for g encra ting said reply descriptor further comprise 

said at least one predefined condition is not met upon instructions for writing said content field to a reply-post 

occurrence of an event selected from the group consisting t >u ffo rj and further comprising: 

of: execution of said command is not completed, execution a sub . codc fcT ua nsmitting a system interrupt over 
of said command is not completed after a retry, said com- ^ m c { medium for a host-based driver 
mand is made at an improper time, an allotted tune for so ^ * [ descriptor> 
execution of said command is exceeded, unsuccessful data r * r ^ . lnr ani1 
transfer of any portion of the request message, quantity of a third sub-code for reading said reply descriptor; and 
data transferred exceeds byte count specifications, quantity a fourth sub-code for correlating said reply descriptor 
of data transferred is less-tban byte count specifications, with said corresponding I/O request message and noti- 
processor resources are insufficient to execute said 55 fying an originating-caller of a completion results, 
command, at least one field of the request message com- 23. The program code of claim 22 wherein each said 
prises invalid data, at least one value from the request predefined condition is met aod said content field comprises 
message is out of range, any data transferred is insufficient data copied from said I/O request message including an 
to execute said command, hardware interface of the message identifier selected from the group consisting of: an address 
passing medium is incompatible with a target device, com- 60 to a storage space in a memory, an index value to a table, an 
munications protocol utilized by the message passing index vahie to a list, an index value to a register, an index 
medium is incompatible with a target device, an unreoov- value lo a stack, an index value to an array, and content-data 
erable bus parity error has occurred, a task management associated with a hardware assisted CAM; said third sub- 
function has failed, a host processor aborts the request code comprises instructions for reading into a host-based 
message, and a target device node has logged-off. 65 memory; and said fourth program sub-code comprises 

17. The method of claim 12 wherein said predefined instructions for correlating said request message identifier of 
condition is met, and said step of generating said reply said reply descriptor with the I/O request message. 



07/31/2003, EAST Version: 1.04.0000 



US 6,591,310 Bl 



23 



24, The program code of claim 22 wherein said at least 
one predefined condition is not met because execution of at 
least one command included in said I/O request message 
was not completed and said content field comprises said 
information, said information to comprise an address to an 
available reply frame buffer bcated in a host memory; and 
said address is one from a plurality of addresses, each of 



24 



which identities a location of a corresponding reply &ame 
buffer residing in said host memory, 

2?. The program code of claim 24 wherein said third 
sub-code comprises instructions for reading said reply 
descriptor from a reply-post buffer. 
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SYSTEM FOR HANDLING AN The USB architecture categorizes peripheral devices f a 

ASYNCHRONOUS INTERRUPT A computer system (e.g., a personal computer system) by 

irMTVirocAi cfdtat RUS DEVICE classes including audio devices, comrnunicaUoos devices, 

UNIVERSAL SERIAL BUS DEVICK, ^ 

*^ «• « f .f. < storage devices, and others. The HID class includes devices 

A portion of the disclosure of this patent document 5 «J ge biimans ^ C0Qtro , sorac facct of a 

contains material which is subject to copyright protecUon. uler . fi orations. Devices within this class may consist 

The copyright owner has no objection to the facsimile Qf ^ foUow £ g lypcs: 

reproducuonby anyoneof the palent document or U)epat^ and printing devices; 

disclosure, as it appears in the Patent and Trademark Office J nftfl f rftk . 5 

patent file or records, but otherwise reserves all copyright 10 ^ dcviccs ^ .3 lelephones 

nghls whatsoever. (dialer), VCR remote controls, and game simulation 

APPENDIX devices; and 

devices that may not control the operation of a device, but 

This application includes a Microfiche Appendix which provide data in a format similar to other HID devices, 

contains 2 sheets and 121 frames, containing a source code 15 jj^ tjsjj architecture defines a layered software scheme 

listing and data structures. This Appendix shows an example which includes, at the highest level, client drivers; at an 

of a particular embodiment of the present invention incor- intermediate level, USB system software; and at the lowest 

poraling features thereof which are described in detail level, host controller software. Transactions performed over 

below. the USB are controlled by the client driver. The device (or 

20 bub client) may be class specific or vendor specific. 
BACKGROUND Accoidingly, each hub client requires a corresponding client 
1 Field of the Invention driver which is tailored to the specific device class or device 
The described embodiments a^d^ , ^ 
devices of a computer system^ Id particular, the described ^ ^ctlcs the neeessaty bandwidth 
embodiments relate to methods and processes of communi- ^ ^ ^ dirccls foe to its destination hub 
cation between such peripheral devices and a host unit. c ^ nL ^ hQSl confer software communicates with a 
Z Related Art USB host controller for the actual transmission of control 
Personal computer (PQ designs from the early 1980s and data informalion to and from the USB devices, 
have implemented peripheral devices according to a para- 30 The USB architecture supports four modes of transferring 
digm which assigns each peripheral device a specific inter- data between the USB devices and the host These types of 
rupt line. In some cases a peripheral device is assigned a transfers are categorized as follows: Interrupt Transfers, 
direct memory access (DMA) channel IBM and other Bulk Transfers, Isochronous Transfers, and Control Trans- 
manufactures assigned these resources to particular pcripb- fers. An Interrupt Transfer is used for devices that are 
eral devices which became the standard I/O locations, inter- 35 typically thought of as interrupt driven devices. Current 
rupt lines and DMA channels used by software developers to USB designs typically call for periodically polling the USB 
facilitate communication with a given peripheral device. devices which are interrupt driven to determine whether the 
These standard PC peripheral interfaces (e,g., serial and device has data to transfer. Control Transfers typically send 
parallel connections) support the standard attachment of a specific requests to USB devices from the host. Control 
single device. Only one peripheral device can typically be 40 Transfers are typically performed during device configura- 
attacbed at any time. Thus, adding a peripheral with new tion. Id a Control Transfer, a special transfer sequence is 
design to a computer system frequently requires a costly used to pass requests to a device, sometimes followed by 
decision of adding a new expansion card that plugs into an data transfer, and concluded with a status completion indi- 
expansion bus (e.g., ISA/EISA or PCI) to create an attach- cation. 

ment point for the new device. Also, these early PC designs 45 A main objective of the USB architecture is to allow many 

do not support "plug and play" attachment of devices. If a types of devices to be coupled as peripherals. The host 

new peripheral device is to be attached while the operating typically periodically polls devices coupled to the USB to 

system of the computer system is running, the user typically determine the characteristics of this device. In response, the 

needs to re-boot the computer system after attaching the polled devices provide a number of "Descriptors'' to the host 
device so that the Basic Input/Output System (BIOS) con- 50 software to identify its characteristics. These Descriptors 

figures the system to associate an interrupt line with the include a "Device Descriptor" "Configuration Descriptor," 

newly attached peripheral device. "Interface Descriptor," and "Endpoint Descriptor/' HID 

Tne Universal Serial Bus (USB) design standard as devices typically additionally have an "Entity Descriptor" as 

described in the "Universal Serial Bus Specification" (Rev. indicated in the "Universal Serial Bus (USB) Device Class 
1 0, Jan. 15, 1996) published by Compaq, Digital Equipment 55 Definition for Human Interface Devices (HID) (version 1.0, 

Corp., IBM PC Co., Intel Corp., Microsoft Corp., NEC and September 1996) published by the USB Implemented 

Northern Telecom provides a new peripheral attachment Forum. 

standard to overcome the above described shortcomings of While the USB standard provides a basic architecture 

the earlier scheme. In the USB architecture, multiple periph- which may overcome the shortcomings of the earlier sys- 
cral devices may be coupled to a single USB controller. A 60 terns for peripheral device attachment and communication, 

corresponding software driver supported by the host oper- the USB standard does not provide significant details as to 

ating system handles inputs from the USB controller. USB how to integrate the USB architecture into a current PC 

systems typically include a root bub coupled to a host design. Thus, there is a need for developing cost effective 

controller for handling all communication between the host and efficient methods for implementing the USB arcbilec- 
and USB devices through a root port. USB systems support 65 tare to facilitate communication with the many types of 

additional hubs coupled to the root port to provide additional peripheral devices which may be attached to a host computer 

ports for receiving USB devices. through a USB. 
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SUMMARY the stored data packet Id this manner, inputs from multiple 

... - . . . • . controls on the USB device may be transmitted to applica- 

ADObjcclofanembodnnen o he present to execul5ngon ^ ^ io Interrupt TYaSfcr. 

provide a system of communicaUon between a host com- , B ....... , • . 

outer and a peripheral device associated with toe applica- t Yel "ottw embodiment f the preseot uvcn«ion is 

tfoos programs executing on the host computer. 5 Erected to a host computer system capable of altachiog to a 

~ i" u &* B ' us mB * peripheral device through a port to receive data transfers, 

b to provide an implementation of a Unrversa ScnalBus ^j^^^^^ preferably includes logic ibr 

(USB) architecture which supports communication between „• .u <J7«*!i.i. ,„„,f-« Z m 

a USB and a single USB device which includes a plurality 10 106 of ^^S^SZSJSS£ 

f i 1 rid' 1 device id response to an attachment of Ihe peripheral device 

ot controls an isp ys. ^ ^ ^ host computer, and circuitry for detecting an a data 

Aiwmerobjectofanembodimcmofthepreseiitinvenuon fl( mc ^ host ^mptex system further 

is to provide software drivers executable on a processor of Chides logic for selectively storing the data packet of the 

a host computer which facilitate icommumcation between a dc( ^ dMalwosfcrinaD ^^ 

peripheral device attached to a host computer and applica- 15 ^ q{ ^ faost ul6r syst£m & enabled to receive data 

lion programs executing on the processor of (he host com- ^ Sllfficicnl mcraory ^ allocatabk to store the 

P utcr * data packet Thus, applications executing on the host com- 

Briefly, an embodiment of the present invention is pulcr systcm may asynchronously receive inputs from the 

directed to a computer system including a host having a peripheral device, 
processor and al least one port capable of attaching to at least 2 o 

one peripheral device. The host includes logic for associat- BRIEF DESCRIPTION OF THE FIGURES 

ing the attached peripheral device with one of a particular computer, system which includes a Uni- 

permhend device typ* logic for associating the attached fius r^^ aC cording to an embodiment, 

peripheral device with an instance of a software driver v _ „ e . _ , 

executable on Ihe processor; and logic for enabling coramn- y na 2 * «»bodiment of a control and display 

nicalion between the attached peripheral device and the host panel of the USB peripheral device of the embodiment of 

upon a detecting a condition indicating reliable data transfer FIG. 1. 

between the attached peripheral device and the host The FIG. 3 shows a second embodiment of a control and 

software driver is preferably tailored to supporting commu- display panel of the USB peripheral device of the embodi- 

nication between peripheral devices of the associated par- 30 ment of FIG. 1. 

licular type and the host FIG. 4 shows an embodiment of the software layers 

Another embodiment of the present invention is directed executing on a processor of the computer system of FIG. 1 

to a computer system including a host having a processor, for facilitating communication with a USB peripheral 

and being capable of attaching to at least one peripheral device. 

device through at least one port The host includes logic for 35 ^IG. 5 shows a functional flow diagram of an embodiment 

associating an attached peripheral device with an instance of 0 f me 'device driver initialization process of the HID sofi- 

a software driver executable on the processor to support waic driver of FIG. 4. 

communication between the attached peripheral device and piQS $a ^ . u ^ a flow diagram of 

the host, and logic for associating the instance of the ombodiment ofthc process for handling an input/output 

software dnver with at least one application program execut- 40 p ac ket at the HID software driver of FIG. 4. 

ing on ihe processor. The instance o .*'™^J™f \iQ.7^*to*^toto^* anembodiment 

preferably responsive to calls from the at least ooe associ- r ™ ' ? Mm ^SL^ 11B ;„ f ™ 1ri , 

ated applSn program. The host also includes logic for f^^*' H^tS 

mainla^ing the mslSce of the software driver while the at J* lbc USB deV3Ce at ^ 1110 software dnvcr of FIG ' 

least one associated application is executing, independent of 45 4 * 

whether the peripheral device remains attached to the host FIG. 8 shows the format of a portion of a (tola packet 

In this manner, the appHcations may terminate properly, associated with in an Interrupt Transfer according to an 

independent of the attachment of the peripheral device to the embodiment 

host The host also preferably includes logic for terminating DETAILED DESCRIPTION 
the instance of the software driver when the execution of the 50 

at least one application program terminates. This may then An embodiment of the present invention is directed to a 

free the memory resources occupied by the instance. Universal Serial Bus (USB) system for facilitating commu- 

Another embodiment of the present invention is directed nication between a host unit and an enhanced Human 

to a host computer system having a USB controller capable Interface Device (HID). This system includes a protocol for 
of attaching to a USB device through a port. The USB device 55 transferring the information from the enhanced HID to the 

includes a plurality of distinct controls for receiving user host computer and logic at the host computer configured to 

inputs. The host computer system includes logic for asso- receive and transmit information to and from the enhanced 

dating the USB device with exactly one Entity Descriptor HID. Other embodiments include logic for implementing 

and associating each of the plurality of controls with a plug and play capabilities. This logic may be included in a 
distinct data structure. The host computer system further 60 client software driver for the enhanced HID, and enhauce- 

inchides a memory for storing a data packet received in meats to the system software. 

response to an associated Interrupt Transfer initiated at the According to an embodiment, the enhanced HID includes 

USB device. The data packet includes data representative of a number of different features which are preferably sup- 

a plurality of the data structures. Each of the plurality of data ported by either communication from the enhanced HID to 
structures preferably correspond with an input from its 65 the host computer r communication from the bost computer 

associated control The host computer system further to the enhanced HID. Such features supported by commu- 

includes logic for extracting each of Ihe data structures from nicalion from the host computer to the enhanced HID may 
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include, for example, an answering machine lighl and an FIG, 2 shows a control panel 20 of ihe USB device 16 

LED or LCD display. Such feature supported by communi- according to a first embodiment. The user may provide 

cation from ihe enhanced HID to the host computer may inputs to the USB device 16 by pressing one of several 

include, for example, a dial (e.g., a volume knob), a device function selection buttons 26, 27, 28, 30, or 32 to select a 

for providing mouse-like inputs, buttons which provide a s particular function. Depending on the fundi n selected, the 

power or sleep-mode switch, and an infrared pointer for user may also provide additional inputs by turning a volume 

providing VCR-like commands (e.g., play, fast forward, knob 22, or pressing any of buttons 3S, 40, 42, or 44, to 

reverse). Thus, the enhanced HID preferably communicates initiate VCR-like commands. The user may also provide the 

with the host unit through the USB bidirecrionally to support same inputs through controls on the IRC 15 (FIG. 1) which 

its functions. 10 initiates signals which are detected and received at an 

As discussed in greater detail below, the enhanced HID is infrared receiver 24 Bjch of the fiinction selection 

preferably associated with an "Entity Descriptor" which ^itloos 26, 27. 28 30, and 32 are associated with a small 

Supports the communication from the enhanced HID to the Hgbt located ^cUy^ £™£ *^ 

, rt ^ . _ ^ . _ *.,.wi.vu-« button as shown in FIG. 2. Each or lae Lights, including an 

host computer. The EnUty Descnptor preferably establishes preferably indicate whether the assbci- 

"Inpul Reports" which axe data stmctures aeamng the 15 ^ , £unclion £*& CD or unselccted/deselected. 

formal of the data transmitted from the enhanced HID to the Mm$tttXtf9 mcssagc light 34 preferably indicates to the 

host computer. "Output Reports' preferably define the for- Uficr whcn a tcfephone message has been received when the 

mat of the data transmitted from the host computer to the personal computer host 10 including telephony hardware 

enhanced HID. Thus, the host software preferably supports ( nol shown), has been configured to fiinction as a telephone 

the bi-directional communication according the Input and ^ angW ering machine. 

Output Reports. FIG. 3 shows a second embodiment of a control panel 46 
Once the client driver is configured to communicate with of the USB device 16. The control panel 46 differs from the 
the enhanced HID, the enhanced HID can send Input control panel 20 shown in FIG. 2 in that the control panel 46 
Reports for the input features (e.g., buttons, dial, and infra- includes an LCD display 62 which replaces the LEDs 
red pointer) for inputs to the client driver. According to an 25 associated with each of the function selection buttons 26, 27, 
embodiment, this is accomplished through the Interrupt 28, 30, and 32. The LCD 62, in addition to showing the 
Transfer method as discussed above. The client driver sends selection status of the function selection buttons, illuminates 
data in Output Reports to the enhanced HID to support the a status display with respect to the VOUike functions 
output features (e.g.. answering machine light and display). selectable by the buttons 38, 40, 42, and 44. The LCD 62 
This is preferably accomplished using the Control Transfer 30 may also provide other status lnformaUon. 
method of transferring data from the host to the enhanced User inputs to the controls of control panels 20 and 46 are 
HID as discussed above. Accordingly, a single physical USB preferably provided to applications executing on the per- 
device can provide, in effect, multiple virtual input and sonal computer host 10 preferably through Interrupt Trans- 
output devices (e.g„ display, IR pointer, and dial) with a fers to the USB host controller. Additionally, applications 
single USB port and device driver. 35 executing on the personal computer host 10 provide status 
FIG 1 shows the computer system which includes a information to be displayed on the displays (i.e., the status 
personal computer (PQ host 10, a display monitor 18 which of message light 34 and LEDs associated with function 
is coupled to the PC host 10 through a display connection 14, selection buttons 26, 27, 28. 30, and 32, and information to 
and a Universal Serial Bus (USB) device 16 coupled to the be displayed on the LCD 62) via Control Transfers through 
personal computer host 10 through a USB root port 12. The 40 the USB host controller. 

personal computer host 10 also includes USB circuitry, FIG. 4 shows layers of software executing on the micro- 
including a USB host controller, (not shown) as described in processor system of the personal computer host 10 to 
the "Universal Serial Bus Specification" (Rev. 1.0, Jan. 15, support the interaction between applications programs 84 
1996), which is published by Compaq, Digital Equipment and the USB device 16 through the USB. A USB driver 78 
Corp J IBM PC Company, Intel Corp., Microsoft Corp, « (USBD) 1 preferably executes at a higher privilege level than 
NEC, and Northern Telecom, and is incorporated herein by applications programs 84. A human interface device (HID) 
reference. Alternatively, the USB device may be coupled to driver 83 preferably executes at a privilege higher than that 
the USB root port 12 through an intermediary USB hub (not of the applications programs 84 but no higher than that of the 
shown). The personal computer host 10 also includes a USBD 78. According to an embodiment, USBD 78 program 
microprocessor system such as that of a Pentium® design, 50 is provided as part of a Windows 95 or Windows NT 
and sufficient random access memory (RAM) to support a operating system, or as a compatible addition to one of these 
Windows 95® ox Windows NT® operating system. The operating systems. Accordingly, the HID driver 83 may 
personal computer host 10 also preferably hosts a Windows communicate with the USB through a USB driver interface 
95 or Windows NT operating system. Alternatively, other (USBD1) which has been established by Microsoft Corp. in 
operating systems which support the USB architecture as 55 its WDM USB Driver Interface. 

specified in the "Universal Serial Bus Specffication" and the The HID driver 83 includes two modules, the 

"Universal Serial Bus Device Class Definition for Human PMAPI.DLL module 82 and the Enhan_HID.SY5 module 

Interlace Devices (HID), (Version 1.0 Draft, September 80. The PMAPIJDLL module 82 in a Win32 scheme, is 

1996) which is published by the USB Implemented Forum preferably an applications program interface (API) 
and is incorporated herein by reference. 60 dynamic-link library (DLL) which exports callable func- 

As shown in FIGS. 2 and 3, the USB device 16 is tions to the applications programs 84. Accordingly the 

preferably of an HID class and includes various controls and PMAPI.DLL 82 functions preferably support Win32 based 

displays which are enabled by bidirectional communication applications. Thus, to send status information to the USB 

with the personal computer host 10 through the USB hard- device 16 in a Control Transfer, or to receive data from an 
ware and software implemented in the personal computer 65 interrupt transfer initiated at the USB device 16, one of the 

host 10. The USB device 16 also responds to inputs from an applications programs 84 preferably makes a call to one 01 

infrared controller (IRC) 15. more functions in the PMAPI.DLL module 82. 
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The Enhan„HID.SYS module 80 performs several lower FIG. 7 illustrates the functioning of the Enban_JttD.SYS 

level functions. The Enban JHID.SYS module 80 processes module 80 in response to a "call back" event at the USBD 

input/output request packets (IRPs) directed to the USB 78 indicating an Interrupt Transfer. FIG. fa through 6d 

device 16 from cither a function in the PMAPLDLL module illustrates the functioning of the Enban _HID.SYS module 

82 or the operating system. The Enhan_HJD.SYS module 5 «0 in response to an IRP originating at the applications 

7» -J-.— * ^ a— ssassasa Tsssnsssa 

? *?F P B P 7 y ° f ift call back events to associated appKcations, retrieving data 

the USB device 16. io reprc5cnlalivc 0 f j^t Reports rcoeived from the USB 

As indicated by the function selection buttons 26, 27, 28, device 16, and sending data representative of Output 

30, and 32, on the control panel of the USB device 16 (FIGS. Reports to the USB device 16. 

2 and 3), the USB device 16 provides the user with a simple, At FIG. 5, step 101, the USB delects an attachment of the 
convenient, and centralized control of the personal computer USB device 16 and receives information representative of 
host 10 when functioning as a television, an FM radio, a 15 the Device Descriptor associated with the USB device 16 as 
CD/DVD player, a telephone, or a telephone answering discussed above. The received Device Descriptor informa- 
machine. Accordingly, the applications programs 84 corre- tion may indicate whether the USB device 16 is of the type 
spond with the applications programs, used in conjunction shown in FIG. 2 without an LCD, or having a control panel 
with relative hardware devices, which enable the personal such as that shown in FIG. 3 having the LCD display 62. 
computer host 10 to perform these selectable functions as is » Step 102 checks to determine that the Device Descriptor 
understood by those of ordinary skill in the art. associated with the attached USB device 16 correspond with 
7t«v1 / . . „ - _ . A u , a USB device which is supported by the Enhan_.HID.SYS 
A USB device * generally characterized by several module gQ I£ tbesc mod X support the attached device, 
"Descriptors" including a "Device Descriptor, one or more dcyicc eatry for the particular attached device 
"Configuration Descriptors," one or more Interface m ju^pj al slep 104. This creates an instance of the 
Descriptors" associated with each Configuration Descriptor, routines m Enhan_HID£YS module 80 for processing IRPs 
one or more "Endpoint Descriptors" associated with each originating at the operating system or from routines in 
Interface Descriptor as discussed in detail in the Universal PMAPLDLL modules 82, and for handling Interrupt Trans- 
Serial Bus Specification (Revision 1.0) incorporated herein f crs originating at the USB device 16 directed to the appli- 
by reference above. Specific USB devices classified as ^ cations programs 84. 

Human Interface Devices (HID) may be associated with §i C p 104 also initiates an instance of a routine in the 
additional descriptors including a "HID Descriptor" associ- EnhanJBD.SYS module 80 for loading and unloading the 
a ted with an Interface Descriptor, and one or more "Entity instance of these routines. Thus, once the instance is created, 
Descriptors" associated with the HID Descriptor a discussed an£ j hence "loaded" to memory, a routine periodically deter- 
in detafl in the Universal Send Bus device Qass Defirulion mines whether the USB device 16 is still in its attached state 
for Human Interface Devices (Version 1.0) incorporated by ^ whether any applications are supported by the instance, 
reference above. According to an embodiment, the USB jf the USB is no longer attached and no applications are 
device 16 is classified as an HID USB device which is supported by the instance, this routine unloads the instance 
associated with one Device Descriptor, one Configuration to processing resources. 

Descriptor, one Interface Descriptor, one Endpoint It ^ understood that immediately fallowing the attach- 

Descriptor, one HID Descriptor, and one Entity Descriptor. mcnl of to USB 1$ to the USB through the root port 

According to an embodiment, upon detection of an attach- 22» any data received from the USB device 16 may be 
ment of the USB device 16 to the root port 12, or the port corrupted from noise and transients. At step 105, a Deferred 
of an intermediary hub, the USB interrogates the USB Procedure Call (DPC) timer is initiated which causes a delay 
device 16 using a Control Transfer to obtain the associated 4$ f or a specified duration (e.g^ five seconds) to allow tran- 
Device Descriptor, Configuration Descriptor, Interface sients and noise at the connection of the USB device 16 to 
Descriptor, Endpoint Descriptor, and HID Descriptor. The the root port 12 to settle. After this specified delay, process- 
Entity Descriptor defines one or more "Input Reports" which jng proceeds to step 106 which includes setting a device 
provide inputs to the applications programs 84 in response ready flag in a memory location to indicate that data in data 
to user inputs al the USB device 16. Such Input Reports are 50 packets received from the attached USB device 16 in 
preferably included in a serial data packet which is associ- Interrupt Transfers at the USB is reliable, and that the USB 
ated with an Interrupt Transfer received at the USB host may reliably send data to the attached USB device 16 in 
controller. As discuss in greater detail below, this serial data Control Transfers. This memory location including the 
packet is to be written to a buffer location in memory upon device ready flag is preferably write protected at the privi- 
certain conditions to be later retrieved by the applications J5 kg C level of the Euhan_JflD.SYS module 80. 
programs 84, through the HID driver 83. FIGS. 6a through Sd show a flow diagram illustrating the 

As discussed above, the applications programs 64 from functioning of the Enhan_.HID.SYS module 80 in process- 
time to time send data to the USB device 16 to change the ing an IRP initiated by either the operating system or an 
displays to inform the user of the status of various selected applications program (via the PMAPLDLL module 82). Al 
functions. Thus, a set of "Output Reports," arc sent from the 60 step 110, an IRP from either the operating system or the 
applications programs 84 to the USB device 16 using applications is received. Step 112 determines the current 
Control Transfers. stack location of the IRP, and other information related to, or 

FIGS. 5, 6a through 6d 9 and FIG. 7 show a flow diagram associated with, the attached device to which the IRP is 

ulusUatmg me functioning of directed using Microsoft factions provided through the 
H3D.SYS module 80 in response to selected events. FIG. 5 65 USBDI. 

illustrates how the Enhan_JOD.SYS module 80 executes in At step 114, the Enhan_HID.SYS module 80 detennine 

response to an attachment of the USB device 16 to the USB. whether there are sufficient resources to process the IRP. If 



07/31/2003, EAST Version: 1.04.0000 



6,085,265 

9 10 

there are not sufficient resources to process the IRP, a proper ating system so that the handler indicating such a detach- 

error message is generated and control is returned to the OS ment event to ibe operating system is in the proper compal- 

at step 116. Step 118 checks to determine whether the IRP iblc WDM formal. 

is a request to start the device. Either the OS or application Step 220 detects an IRP from the operating system 

may request the Eohan_HID.SYS module SO to start the 5 requesting particular Device Descriptors. For example, the 

device upon detection of the attachment f the USB device operating system may be requesting information as to 

16 to the USB. Thus, ai step 120, the Enhao_HID.SYS whether the attached USB device 16 is of the type having a 

module 80 obtains the Configuration, Interface, and End- control panel 20 as shown in PIG. 2 (without an LCD display 

point Descriptors. An Interrupt Request Pipe from the USB 62) or of the type having a control panel 46 as shown in FIG. 

device to the USB stack is initialized. Also, the DPC timer 3 (with an LCD display (52). Step 222 then calls a lower layer 

is initialized to begin a wait sequence which terminates stack in the USBD 78 to retrieve the Device Descriptor, 

when the PM hardware ready flag is set as discussed above At FIG. 6c, continuing from point C on FIG. 6b, step 302 

in connection with FIG. 5. responds to a request from the operating system inquiring as 

Steps 122. 124, 126, and 128 illustrate a feature which to the number of USB devices 16 which arc coupled to the 
moiu^rstbenumberofdistmctappHcalionswm^aretobe 1S root port 12. It is understood that multiple USB devices 16 

supported by a singular USB device 16 associated with an may be coupled to the root port 12 through an mteimediary 

J^ceofade^ V S , B bub 7?^^ 

80 initiated at step 104. The Enhan_HID.SYS module 80 ^stances of the usame dnver. Accordingly, such a request 

. . v r * v * j^V 1 1 initiates step 304 which returns the number of devices 

maintains a counter -of the number of distinct! applications £ ^ E^ an j iaS YS module 80 to the caller, 

which are supported by the instance of the device dnver. M ^ m a ^ ^ &c systcm to 

Thus, to obtain support of the instance of the device dnver, col f cct dcvice extension information at step 308. 

an application preferably sends an IRP to "open the device ^ m may ^ as a part of a debugging procedure, 

which causes the counter to be incremented at step 124. g| 3U> 314 31fi 31fif 320i and 322 arc directed to 

When an application no longer requires support of the USB pcywcr management requests. Namely, a "suspend* request 
device 16, or its associated instance of the driver, the ^ dclec(e d al s tep 312 and a "resume" request detected at step 

application sends an IRP to "close" the device, thereby 315 iniiUie similarly described processes in the "Advanced 

decreasing the counter at step 128. As such, the Enban_ Power Management (APM) Bios Interface Specification 

H1D.SYS module 80 will not unload the drivers for the USB Revision 1.2, published by Intel Corporation and Microsoft 

device 16 to free up resources (as discussed above in Corporation (February, 1996) incorporated herein by refer* 

connection with step 104) until the counter is decremented 30 ence. Thus, a power suspend request detected at step 312 

to zero. initiates processes set forth in step 314 including a spiodown 

As discussed above, the USB device 16 and its associated of pending IRPs, an abort of any interrupt pipe requests, a 

instance of the driver may support more than one distinct reset of the interrupt pipe, a release of aU previous IRPs, and 

application. For cacb of these applications, the Enhan_ storage of the state of the USB to memory. Detection of a 

HID.SYS module 80 preferably maintains an instance of the 35 power resume request al step 316 initiates processes set forth 

software driver associated with each of the supported appli- in 318 including activating a rchook flag to reinitialize the 

cations. Turning to FIG. 6b t step 206 determines whether the stack and re-associate any pending IRP, and performing 

incoming IRP is to create an additional instance of the other such resume functions, such as restoring the stale of 

software driver to support an additional application. If so, the USB. Other power management events may be detected 

step 208 performs the necessary function to determine the 40 at step 320 which would initiate certain processes to be 

pipe attributes, and the interlace requirements for the addi- carried out in the response to such a request at step 322. 

tional instance to be associated with the application to be As discussed above, a branch to point B is initiated at step 

supported by the additional instance, using, for example, 214 (FIG. 6b) upon detection of an API function request 

standard Microsoft provided routines. from an application. Step 324 determines whether the device 

It is understood that certain applications need to be 45 ready flag has been set as discussed above in connection 

apprised of certain events occurring at the USB device 16 with FIG. 5. If the device ready flag has cot been set, step 

(such as buttons being pushed, knobs being turned, etc.) and 326 returns a code back to the calling application to indicate 

other applications need not be apprised of any events that the device is not ready. Steps 328, 330, 332, and 336 

occurring at the USB device 16. For those applications relate to establishing a protocol between the calling appb- 

requiring knowledge of such events, such applications may so cation and the USB device 16 which is not set forth in the 

initiate an IRP which is then detected at step 210 to request USB Sjxciflcatioii. Thus, these steps may support a propri- 

a single event handler. Upon detection of such request, step etary interface between the calling applications programs 

212 determines the type of signaling required to inform the and the USB device 16. Steps 328 and 330 relate to an 

particular application of such events. For example, if the imtialization of that protocol. Thus, this IRP is preferably the 

applications are hosted 00 an operating system which uses a 55 first IRP to be called after the IRP which inquires as to 

Windows Driver Model (WDM) different from that of the whether the device ready flag is set. Conversely, an IRP 

Enhan_JHD.SYS module 80, step 212 preferably converts requesting the processes at 336 to uninitialize the application 

its signaling to the applications to accommodate the WDM- with the USB device 16 is preferably sent prior to decreasing 

type of the operating system hosting the applications. the device counter at step 128 (pIG. 6a). Step 334 detects a 

At step 214, the Enhan_HID. SYS module 80 responds to 60 command for obtaining device information at step 338 such 

IRPs initialed by an applications programming interface as, for example, information indicating as to whether the 

(API) function call from routines in the PMAPLDLL mod- USB device 16 is of the type shown in FIG. 2 having a 

ule 82. These are discussed in greater detail with reference control panel 20 with no LCD display, or of the type having 

to FIG. 6c. Step 216 detects an IRP from the operating a control panel such as that shown in FIG. 3 with an LCD 

system requesting an indication as to the attachment state of 65 display 62. 

the USB device 16 from the USB. Upon such a detection, It is understood that the USBD 78 may provide a signal 

step 218 determines the proper WDM formal of the oper- to the operating system indicating a detachment of the USB 
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device 16 in response (o polling by the operating system. user inputs ft m the USB device 16 may be included in a 
Turning to FIG. 6tf, at point D, steps 402, 404, 410 and 412 data packet from a single Interrupt Transfer, 
support requests from the operating system indicating a FIG. 8 shows a portion of the data packet associated with 
removal or detachment of the USB device 16. At step 404, an Interrupt Transfer which includes an n-number of Input 
the Enban_HID.SYS module 80 resets the device ready flag 5 Reports. A double word 602 at the leading portion indicates 
which was set when the USB device 16 was attached as ihc number of input reports in the interrupt transfer data 
discussed above with reference to FIG. 5, signals to the packet. N-double words follow in data field 604 which 
applications associated with instances of the software driver identifies the usage or function associated with each of the 
for tbe USB device 16, checks the "open" counter corresponding Input Reports which follow. Field 606 then 
(maintained as described above with reference to steps 122, ]Q includes these n-lnpul Reports. As discussed in greater detail 
124, 126 and 128) lo determine whether the instance of the below with reference to FIG. 7, the receipt of an Interrupt 
driver may be unloaded from tbe system, frees interrupt Transfer initiates a call back event directed to the applica- 
pipes allocated to the instance of the software driver, tions via an associated event handler to indicate that an 
releases semaphores associated with the instance of tbe Interrupt Transfer has occurred and that a corresponding 
software driver, terminates pending read requests from the 15 packet has been stored in a buffer portion of memory, 
applications programs 84, and prepares to delete the object j n response, tbe affected applications program preferably 
associated with the USB device 16. calls routines in PMAPLDLL module 82 to send an IRPto 

Step 410 illustrates a wait sequence which causes the the Enhan_HID.SYS module 60 lo retrieve the number of 
instance of the software driver associated with the detached reports in tbe data packet stored at the double word field 602 
USB device 16 to terminate when certain conditions are met. 20 (FIG. 8). Then, a routine in the PMAPIDLL modules 82 
The Enban_HID.SYS module 80 loops back on iterations of initiates another IRP to retrieve data in field 604 indicating 
this portion of the Enhan JDD.SYS module 80 to step 410 the usage or function associated with each of the n-Input 
unto tbe "open" counter is decremented to zero, indicating Reports in tbe data packet 600. Tbe PMAPIJDLL module 82 
that all of the applications associated with the instance of tbe may also initiate other IRFs to determine other structural 
software driver have acknowledge receipt of a notification 25 information representative of the format of the Input Reports 
the detachment of the USB device 16. When the termination in the data packet 

condition is met at step 410, step 412 performs various Returning to FIG. 6d, the applications in applications 
functions to terminate the instance of the software driver programs 84 corresponding to the functions or usages iden- 
associated with tbe detached device by deleting the symbolic tified in tbe data from portion 604 of the received data packet 
link between the operating system and the USB device 16 30 600 sequentially initiate IRPs to first get tbe input report size 
and deleting the instance of tbe software driver. at steps 424 and 428, and then get the report data at steps 426 

Step 406 indicates a detection of an IRP from the opcr- and 430. Thus, as illustrated in FIG. 8, the field 608 
ating system which is a request to stop the device. This may corresponding to the associated Input Report is retrieved in 
be initiated by events which include power down, an unplug- response to a first IRP from the application corresponding to 
ging of the device, or a user initiated "stop device" event. At 35 the usage or function of the associated Input Report After 
step 408, the Enhan_HID.SYS modules 80 signals to the determining tbe size of the Input Report from the associated 
affected applications, uniuiiializes events associated with the double word field 608, the application initiates a second IRP 
device, closes the device, releases semaphores associated to retrieve the remainder of the report at step 430. Driver 
with the device and frees the portion of memory occupied by run-time process reaches step 432 if the IRP does not 
tbe instance of the software driver associated with the 40 correspond to any supported command. As such, a proper 
device. error code is generated. 

At point F, steps 416 and 418 support requests from an FIG. 7 is a flow diagram illustrating the processing of tbe 
application to poll the USB device using a Control Transfer. Enhao_HID.SYS module 80 in response to the receipt of an 
This capability may enable an application lo support diag- Interrupt Transfer. At step 502, tbe Enhan__HID.SYS mod- 
nosiic functions. Steps 420 and 422 respond to a request 45 ule 80 receives a call back from the USBD 78 indicating the 
from an application to send an Output Report to the USB receipt of an Interrupt Transfer. At step 504, the process 
device 16 using a Control Transfer as discussed above. Here, checks to see if the device ready flag is set as discussed 
referring to tbe embodiments shown in FIGS. 2 and 3, such above in connection with FIG. 5. At step 506, the process 
Output Reports may include information representative of determines whether there are sufficient memory resources to 
changes in tbe status of tbe controls selectable from selec- 50 receive the data packet associated with the Interrupt Trans* 
tioo buttons 26,27, 20 28, 30, 32, and the message light 34. for. If the device ready flag is set and there are sufficient 
In tbe embodiment shown in FIG. 2, these Output Reports resources to receive the data packet associated with the 
may provide inputs to the USB device for changing the Interrupt Transfer, the process at step 510 copies the portion 
status of the LEDs above, and associated with, the selection of the data packet including the Input Reports to an allocated 
buttons. In the embodiment shown in FIG. 3, these Output 55 buffer location, fills the end of tbe report portion with zeros 
Reports would be used to change the state of tbe LCD 62. to fill the remainder of the allocated portion, and signals to 

Steps 424, 426, 428, and 430 correspond to the retrieval tbe applications that an Interrupt Transfer has been received 
of Input Reports. Such Input Reports are preferably part of and that an associated data packet including Input Reports 
a data packet which is associated with an Interrupt Transfer has been stored in the memory buffer. In response to this 
which has been written to a buffer location in memory as 60 signal to tbe applications, as discussed above, the applica- 
dscussed in greater detail with reference to FIG. 7 below. tions may initiate IRFs to obtain the number of Input Reports 
Embodiments of the control panel of the USB device 16 as in the stored data packet, the usages/functions associated 
shown in FIGS. 2 and 3 include function selection buttons, with each of the Input Reports, and other format informa- 
VCR-like controls, the volume knob 22, and tbe IRR 24 to tion. If step 504 determines that the device ready flag is not 
receive inputs from the IRC 15. Each f these actuation 65 set, or if step 506 determines that there are not sufficient 
features on the control panel may correspond with a separate resources to receive tbe data packet associated with the 
Input Report Thus, according to an embodiment, multiple Interrupt Transfer, step 508 bypasses the signal to the 
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applications and step 512 sets the next interrupt IRP and puts 
the Enhan_HID.SYS 80 in a state of wailing for mother call 
back event. 

While toe description above refers to particular embodi- 
ments of the present invention, it will be understood that 
many modifications may be made without departing from 
the spirit thereof. The accompanying claims are intended to 
cover such modifications as would fall within the true scope 
and spirit of the present invention. 

The presently disclosed embodiments are therefore to be 
considered in all respects as illustrative and not restrictive, 
the scope of toe invention being indicated by the appended 
claims, rather than the foregoing description, and all changes 
which come within the meaning and range of equivalency of 
the claims are therefore intended to be embraced therein. 

What is claimed is: 

1. In a computer system including a host having a 
processor, a Universal Serial Bus (USB) host controller and 
a port for attaching to a USB device, the USB host controller 
being capable of coupling to the USB device through an 
attachment to toe port, the USB host controller including 
circuitry fox detecting an attachment of the USB device to 
the port for enabling a bidirectional communication channel 
between the host unit and the USB device, the improvement 
comprising: 

logic for detecting a condition indicative of a degree of 
reliability of the bi-directional communication channel 
upon attachment of USB device to the at least one port; 
and 

logic for enabling at least one of transmission of a Control 
Transfer from the host to the attached USB device and 
receipt of data provided by the attached USB device to 
the host in an Interrupt Transfer upon detecting the 
condition indicative of a degree of reliability in the 
bi-directional communication channel enabled by the 
attachment of the USB device. 

2. The computer system of claim 1, wherein the enabling 
logic enables the at least one of transmission of a Control 
Transfer from the host to the attached USB device and 
receipt of data provided by the attached USB device to the 
host in an Interrupt Transfer following a set time period 
following a detection of an attachment of the USB device to 
the USB controller. 

3. The computer system of claim 1, wherein the enabling 
logic inhibits the transmission of a Control Transfer from the 
host to the attached USB device and the receipt of data 
provided by the attached USB device to the host in an 
Interrupt Transfer until the detection of the condition indica- 
tive of a degree of reliability in a bi-directional communi- 
cation channel enabled by the attachment of the USB device. 

4. In a computer system including a host having a 
processor, a Universal Serial Bus (USB) host controller and 
a port for attaching to a USB device, the processor executing 
at least one applications program and one or more instances 
of a software driver, the software driver being capable of 
supporting communication between an attached USB device 
and the host, the USB host controller being capable of 
coupling to the USB device through an attachment to the 
port, the USB host controller including circuitry for detect- 
ing an attachment of the USB device to the port or a 
detachment of the USB device from the port, (he improve- 
ment comprising: 

logic for associating an attachment of the USB device 
with an instance of the software driver; 

logic for associating the instance of the software driver 
with at least one application program executing on the 
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processor, the instance of the software driver being 
responsive to calls from the at least one associated 
application program; 
logic for maintaining the instance of the software driver 
while the at least one application is executing, inde- 
pendent of whether the USB device remains attached to 
the port; and 

logic for terminating the instance of the software driver in 
response to one of a termination of the execution of the 
at least one application program and an acknowledg- 
ment that the application program has been notified of 
a detachment of the USB device. 

5. The computer system of claim 4, the improvement 
further including: 

logic for maintaining a count of the executing application 
programs which are associated with the instance of the 
software driver and decrementing the count when one 
of the execution of an associated application terminates 
and an acknowledgment that the associated application 
has been notified of a detachment of the USB device; 
and 

logic for terminating the instance of the software driver 
when the count is decremented to zero. 

6. The computer system of claim 4, the host further 
including a portion of memory which is allocated to the 
instance of the software driver, wherein the improvement 
further includes logic for de-allocating the memory allocated 
to the instance of the software driver when the instance of 
the software driver terminates. 

7. A host computer system having a Universal Serial Bus 
30 (USB) host controller capable of attaching to a USB device 

through a port, the USB device having a plurality of distinct 
controls for receiving user inputs, the host computer system 
comprising: 

logic for associating the USB device with exactly one 
Entity Descriptor which defines a plurality of data 
structures, each data structure being associated with 
one of the distinct controls; 
a memory for storing a data packet received in response 
to an associated Interrupt Transfer initiated at the USB 
device, the data packet including data representative of 
a plurality of said data structures, each of the plurality 
of data structures including data representative of user 
inputs from its associated control; and 
logic for extracting each of the plurality of data structures 
from the stored data packet 

8. The host computer system of claim 7, the host computer 
system further including: 

a processor for executing application programs thereon; 
logic for associating each of the reports extracted from the 

stored data packet with an application program; and 
logic for notifying each application program associated 
with an extracted data structure of the receipt of said 
extracted data structure. 

9. The host computer system of claim 7, wherein the logic 
for extracting data structures from the stored data packet 
includes: 

logic for determine the number of data structures included 

in the stored data packet; 
logic for associating each of the data structures in the 
stored data packet with one of the controls of the USB 
device; 

logic for detennining a memory location of each data 

structure in the stored data packet; and 
logic for retrieving each data structure in the stored data 
packet at its associated memory location by executing 
an application program associated with the data struc- 
ture. 
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10. A host computer system having a Universal Serial Bus 
(USB) controller capable of attaching to a USB device 
through a port lo receive Interrupt Transfers, the Interrupt 
Transfers having a data packet associated therewith* the hast 
computer system comprising: 

logic for enabling the receipt of Interrupt Transfers from 
the USB device at the USB controller in response to an 
attachment of the USB device to the USB controller, 

circuitry for detecting an Interrupt Transfer at the port; 
and 

logic for selectively storing the data packet of the detected 
interrupt transfer in an allocatable memory when at 
least one of the host computer system is enabled to 
receive Interrupt Transfers and sufficient memory at the 
host computer system is allocatable to store the data 
packet. 

11. The host computer system of claim 10, wherein the 
logic for enabling the receipt of Interrupt Transfers further 
includes: 

logic for associating the attached USB device with an 

instance of a software driver; 
logic for detecting of a condition indicative of a degree of 

reliability of data received from Interrupt Transfers 

initiated at the attached USB device. 

12. The host computer system of claim 11, wherein the 
logic detecting a degree of reliability of the data received 
from Interrupt Transfers initiated at the attached USB device 
detects a passage of a set time period following a detection 
of an attachment of the USB device to the USB controller. 

13. The host computer system of claim 10, the host 
computer system further comprising logic for transmitting 30 
an error signal to the attached USB device upon detection of 
an Interrupt Transfer when the host computer system is not 
enabled to receive the Interrupt Transfer or there is not 
sufficient memory allocatable to store the associated data 
packet. 35 

14. A computer readable medium for use in conjunction 
with a computer system including a host having a processor 
and a Universal Serial Bus (USB) host controller, the USB 
host controller being capable of attaching to at least one 
USB device through at least one port, the computer readable 40 
medium including computer readable instructions encoded 
thereon for 

detecting an attachment of a USB device to the at least 
one port; and 

enabling at least one of transmission of a Control Transfer 45 
from the host to the attached USB device and receipt of 
data provided by the attached USB device to the host in 
an Interrupt Transfer upon detection of a condition 
indicative of a degree of reliability in a bi-directional 
communication channel enabled by the attachment of 50 
the USB device. 

15. The computer readable medium of claim 14, the 
computer readable medium further including computer read- 
able instructions encoded thereon for enabling the at least 
one of transmission of a Control Transfer from the host to 55 
the attached USB device and receipt of data provided by the 
attached USB device to the host in an Interrupt Transfer 
following a set time period following a detection of an 
attachment of the USB device to the USB controller. 

16. The computer readable medium of claim 14, the 60 
computer readable medium further including computer read- 
able instructions encoded thereon for inhibiting the trans- 
mission of a Control Transfer from the host to the attached 
USB device and the receipt of data provided by the attached 
USB device to the host in an Interrupt Transfer until the 65 
detection of the condition indicative of the degree of reli- 
ability. 



17. A computer readable medium for use in conjunction 
with a computer system including a host having a processor 
and a Universal Serial Bus (USB) host controller, the USB 
host controller being capable of attaching to at least one 
USB device through at least one port, the computer readable 
medium including computer readable instructions encoded 
thereon for 

associating an attached USB device with an instance of a 
software driver executable on the processor, the soft- 
ware driver being capable of supporting communica- 
tion between the attached USB device and the host; 
associating the instance of the software driver with at least 
one application program executing on the processor, 
the instance of the software driver being responsive to 
calls from the at least one associated application pro- 
gram; 

maintaining the instance of the software driver while the 
at least one application is executing, independent of 
whether the USB device remains attached to the USB; 
and 

terminating the instance of the software driver in response 
to one of a termination of the execution of the at least 
one application program and an acknowledgment that 
the application program has been notified of a detach- 
ment of the USB device. 
16. The computer readable medium of claim 17, the 
computer readable medium further including computer read- 
able instructions encoded thereon for 



maintaining a count of the executing application programs 
which are associated with the instance of the software 
driver and decrementing the count when one of the 
execution of an associated application terminates and 
an acknowledgment that the associated application has 
been notified of a detachment of the USB device; and 

terminating the instance of the software driver when the 
count is decremented to zero. 

19. The computer readable medium of claim 17, wherein 
the host further includes a portion of memory which is 
allocated to the instance of the software driver, wherein the 
computer readable medium further includes computer read- 
able instructions encoded thereon for de-allocating the 
memory allocated to the instance of the software driver 
when the instance of the software driver terminates. 

20. A computer readable medium for use in conjunction 
with a host computer system having a Universal Serial Bus 
(USB) host controller capable of attaching lo a USB device 
through a port, the USB device having a plurality of distinct 
controls for receiving user inputs, the computer readable 
medium including computer readable instructions encoded 
thereon for. 

associating the USB device with exactly one Entity 
Descriptor which defines a plurality of data structures, 
each data structure being associated with one of the 
distinct controls; 
storing in a memory associated with the host computer 
system a data packet received in response to an asso- 
ciated Interrupt Transfer initiated at the USB device, 
the data packet including data representative of a 
plurality of said data structures, each of the plurality of 
data structures including data representative of user 
inputs from its associated control; and 
extracting each of the plurality of data structures from the 

stored data packet 
21. The computer readable medium of claim 20, wherein 
the host computer system further includes a processor for 
executing application programs thereon, and wherein the 
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computer readable medium further includes computer read- 
able instructions encoded thereon for. associating each of 
the reports extracted from the stored data packet with an 
application program; and 
notifying each application program associated with an 

extracted data structure f the receipt of said extracted 

data structure. 

22. Hie computer readable medium of claim 20, the 
computer readable medium further including computer read- 
able instructions encoded thereon for 

determining a number of data structures included in the 
stored data packet; 

associating each of the data structures in tbe stored data 
packet with one of tbe controls of the USB device; 

determining a memory location of each data structure in 
the stored data packet; and 

retrieving each data structure in the stored data packet at 
its associated memory location by executing an appli- 
cation program associated with the data structure. 

23. A computer readable medium for use in conjunction 
with a host computer system having a Universal Serial Bus 
(USB) controller capable of attaching to a USB device 
through a port to receive Interrupt Transfers, the Interrupt 
Transfers having a data packet associated therewith, the 
computer readable medium including computer readable 
instructions encoded thereon fbn 

enabling the receipt of Interrupt Transfers from the USB 
device at the USB controller in response to an attach- 
ment of the USB device to the USB controller; 

detecting an Interrupt Transfer at the port; and 
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selectively storing tbe data packet of the detected interrupt 
transfer in an allocalabie memory when at least one of 
the host computer system is enabled to receive Interrupt 
Transfers and sufficient memory at tbe host computer 
5 system is allocatable to store tbe data packet. 

24. The computer readable medium of claim 23, the 
computer readable medium further including computer read- 
able instructions encoded thereon ion 
]0 associating the attached USB device with an instance of 
a software driver; and 
detecting a condition indicative of a degree of reliability 
of data received from Interrupt Transfers initiated at the 
attached USB device. 
35 25. The computer readable medium of claim 24, tbe 
computer readable medium further including computer read- 
able instructions encoded thereon for detecting a passage of 
a set time period following a detection of an attachment of 
the USB device to the USB controller to determine a degree 
20 of reliability of the data received from Interrupt Transfers 
initiated at the attached USB device detects. 

26. The computer readable medium of claim 23, tbe 
computer readable medium further including computer read- 
able instructions encoded thereon for transmitting an error 
25 signal to the attached USB device upon detection of an 
Interrupt Transfer when the host computer system is not 
enabled to receive tbe Interrupt Transfer or there is not 
sufficient memory allocalabie to store the associated data 
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UNIVERSAL SERIAL BUS TO PARALLEL transmission of a byte of information in both directions 

BUS SIGNAL CONVERTER AND METHOD between the host computer and the printer. 

OF CONVERSION The vast majority of printers of whatever type, make and 

manufacture, thai are in use and are currently being manu- 
This application is a continuation of Sen No. 08/974,736 5 factored in the United States, are for use with one or more 
filed Nov. 19, 1997. of these communications protocols in conjunction with a 

parallel port conforming to the IEEE 1284 standard. 
BACKGROUND OF THE INVENTION other computer peripherals, including document scanners 

1_ Technical Field and peripheral memory storage devices, also utilize the 

L, ; . „ , , 4 , ^ _ l° parallel port conforming to the IEEE 1284 standard, and 

mVN ? ,l0D 1 ge^^y relates to a signal converter ^for ^ ^mvniczMcns protocols. However, because of the 
convening signals transmitted from a Unmrsd Serial Bus diffcrin ^ may be addi tional protocols 

conforming to standards, as implemented by the Unrversal ^ ^ ^per^heral driver resident in the host which are 
Serial Bus Impleinentatioo Forum to si^aU transited ^andard £ compatibility mode, enhanced capabilities 

from a parallel port conforming to IEEE Standard 1284 and 1S ^ mc6 t t or in the extended parallel port mode. 

reversc - The UDfversal Serial Bus, USB, communication protocol 

2. Background ^ (jyf ercDl in some fundamental areas, not the least of which 

Throughout its history, the computer and computer USB is a serial communications protocol, which is 
peripheral electronics industry has made a continuing effort designed around shift registers. As a result, it is not possible 
to standardize input/output ports and signal or conmaunica- 20 to connect the input/output, I/O, USB port to a device 
tion protocols. This has been, in large p art, accomplished by designed to receive and transmit data through an I/O parallel 
adoption and adherence to industry standards such as those port conforming to the IEEE 1284 standard. Accordingly, 
set forth by the Institute of Electrical and Electronic Engi- what is needed is a device which can be used to connect a 
neers (IEEE). USB ported host to a peripheral as a parallel ported, IEEE 

A number of computer peripherals, including most print- 25 1284 conforming, host. It is one object of this invention to 
ing devices, some paper and photograph scanners, and also provide a converter which can operate in an automatic mode 
some peripheral memory storage devices, are designed for as a fully compliant USB device receiving and sending data 
interconnection to a host computer through the standard, and using USB communications protocols, and as a 
well known parallel port connector which conforms to the re-transmitting device sending and receiving data to an 
TERR 1284 standard as adopted in the fall of 1994. 30 attached peripheral device as a fully compliant parallel port 

With printers, the typical information flow and processing device, all done in a transparent manner wherein that the 
steps can be demonstrated by simple example as follows: bost need have no knowledge that the protocol translation is 
The document to be printed is first generated in the host occurring. 

computer using information processing application 3S It is another object of this invention to provide a signal 
software, such as a word processing, or a spread sheet, converter which can operate in a register mode wherein the 
program. The document, in the form of an electronic file of signal converter contains a set of registers which emulate 
information, is then processed in a second software program, those found in standard computer parallel port hardware, 
usually called a printer driver, where the information from citmviapv nv top invention 

the original applkation file is converted into a string of data ^ SUMMARY OF TOE INVENTION 

bits which will ultimately be used by the printer to generate These objects are accomplished in a serial to parallel port 
pixels in the complete dithered printed image. The printer signal converter which is preferably manufactured as a 
driver software will perform such functions as scaling of one-chip serial to parallel port signal converter which con- 
pixels, addressing, adding color data, and often times even verts a bit stream signal coming from the universal serial bus 
compressing the data in the event of redundant data. 4$ of a host device to a parallel signal confor ming to the 

This data stream is then passed through a third, lower Institute of Electronic and Electrical Engineers (IEEE) 1284 
level driver software application, usually the operating sys- signal protocol. It is connected to, and appears to a universal 
tern software, where it is assembled into bytes suitable for serial bus (USB) of a host, as a standard USB device, and to 
transmission through the host computer's parallel port to the a peripheral device as an IEEE 1284 host It operates in two 
computer peripheral, which in this example is a printer. Over so different modes, the first being the automatic mode wherein 
the years, a number of communication protocols have been it acts as a fully compliant bi-directional USB device 
developed for use in communication between the host receiving USB data packets and retransmitting that data to 
computer and the printer peripheral. The earliest and sdn> the attached peripheral device transparently as if it were an 
plest of these protocols is known as the compatibility mode IEEE 1284 host In automatic mode, the actual host device 
protocol, in which data is sent from the host computer to the J5 has no knowledge that the protocol translation is occurring, 
printer in one direction only, in eight bit, or one byte, parallel In the second mode, register mode, the signal converter 
format. A more advanced version of compatibility mode contains a set of registers which emulate those found in 
includes what is known as the NIBBLE mode protocol standard, IEEE compliant parallel port hardware, 
which provides or allows specific information to flow back The serial to parallel port signal converter can be under- 
from the printer to the host computer over dedicated pins of 50 s iood representationally as a series of modules, the first 
the parallel port, four bits at a time, and enables the printer being the universal serial bus device controller module 
to report to the host computer status conditions. which is connected to the universal device controller 

Still later, the Extended Capabilities Fort (ECP) protocol interface, a buffer memory, a read-only memory, and a 
was developed wherein eight bits, one byte, of information parallel port interface module. The universal serial bus 
can flow in either direction between the bost computer and 65 device controller is an application specific standard product 
the peripheral printer. Another protocol, known as the developed by Sand Microelectronics, Inc., and available 
Enhanced Parallel Port (EPF) protocol permits simultaneous from Lucent Technologies and is known by the macrosell 
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name of UDC as published in the Lucent Technologies FIG. & is a stale transition diagram for the controller 

System ASIC data book dated September, 199(5. It functions operations of the parallel port interface module; 

as a controller for managing signals to and from the uni- piG. 9 ^ a S ( a(c transition diagram for the master state 

versa! serial bus of the host, including generation and machine operations of Ibc parallel port interface module; 

transmission of slut codes, data strobes, and control and S nG JQ fc fl ^ transitioD diagram of ^ 0^005 f 

data signals. It handles most of the low level USB protocol thc OTpalibl1ity mode host for the parallel port interface 

operations and converts USB bit streams of data to a stream module* 

of bytes, plus control and status information. It is used to _ T _ ' . _ , 4 . . . . . 

separate the cyclical redundancy check signal from the data, k * IG : » » a *!* u-a^Uon magramof the NIBBLE mode 

while it keeps the data in a register and verifies the accuracy 10 b^t of tte paraJId port interface module; 

of the cyclical redundancy check signal, and is used to send HO* 32 is a master state transition diagram of the ECP 

acknowledgment or non-acknowledgment signals to a uni- host operations of the parallel port interface module; 

versal device controller interface. The universal serial bus FIG. 13 is a diagram of the ECP host in register mode 

device controller also performs an additional function in that operations of the parallel port interface module; 

it stores the information about the end points of data streams 15 FIG. 14 is a state transition diagram of the EPP host 

and the devices supported by the serial to parallel port signal operations in register mode operations for the parallel port 

converter. interface module. 

A universal device controller interface is provided and is „ ^ 

utilized as a control device for thc universal serial bus device DESCRIPTION OF TOE PREFERRED 

controller, adding support for the USB protocol features not 20 EMBODIMENT 

handled directly by thc universal serial bus device controller. The serial to parallel port signal converter 10 of the 

Some of these additional features include decoding of present invention is shown in a high-level block in FIG. 1. 

descriptor requests, and providing of descriptor data, which it is preferably manufactured as a one-chip serial to parallel 

is sou reed by the read-only memory by way of a buffer port signal converter which converts a bit stream signal 

memory. It also provides support for all printer class device 25 coming from the universal serial bus of a host device to a 

commands and support which is unique and specific to the parallel signal conforming to Institute of Electronic and 

present invention and not part of any standard specification. Electrical Engineers (IEEE 1284) signal protocol. It is 

The universal device controller interface has ports for com- connected to, and appears, to a universal serial bus of a host, 

municaling to the buffer memory and also a port for com- hereinafter USB, as a standard USB device, and to a 

municating directly with the parallel port interface module. 30 peripheral device as an rettP. 1284 host It operates in two 

A buffer memory is provided and is a block which has different modes, the first being the automatic mode, wherein 

byte-oriented storage for multiple data packs, which in the it acts as a fully compliant bi-directional USB device 

preferred embodiment are packets of sixty-four (64) bytes. receiving USB data packets and retransmitting that data to 

There are independent input and output channels for two the attached peripheral device transparently as if it were a 

packets of one hundred twenty eight (128) bytes of actual 35 IEEE 1284 host In automatic mode, the actual host device 

value in each direction. has no knowledge that the protocol translation is occurring. 

The parallel port interface module Is made of hardware In the second mode, register mode, the signal converter 

for a fully automatic support of Institute of Electronic and contains a set of registers which emulate those found in 

Electrical Engineers (IEEE) 1284 standardized ^ standard, IEEE 1284 compliant parallel port hardware, 

compatibility, NIBBLE, extended capability port and As shown in FIG. 1, the serial to parallel port signal 

enhanced parallel port with and without run length encoded converter 10 can be shown representationaUy as a series of 

communications modes. It is intended to emulate normal modules, the first being the universal serial bus device 

parallel port hardware such as might be implemented with controller module 12 to which is connected the universal 

an industry standard super-l/O chip. It also includes logic to 4$ device controller interface 14, buffer memory 16, read only 

provide control for the automatic and register based parallel memory 18, and parallel port interface module 20. The 

port logic, including readable and write able registers which universal serial bus device controller 12 is, in the preferred 

emulate those found in standard personal computers. It also embodiment, an application specific standard product devel- 

includes necessary support logic, such as timers, counters, oped by Sand Microelectronics, Inc., and available from 

digital filters and post stretchers. 5Q Lucent Technologies®, and is known by the MACROCELL 

name of UDC as published in the_JLucent Technologies 

BRIEF DESCRIPTION OF THE DRAWINGS Syslem asjc Data Book dated September, 1996. 

FIG. 1 is a high level block diagram of the serial bus to Universal serial bus device controller 12 is known 10 the 

parallel bus signal converter; prior art and its functions play no part of the present 

FIGS. 2A through 2D is a flow chart block diagram of the 55 invention, except as a controller for a managing signals to 

universal device controller interface; ' and from thc universal serial bus of the host in the manner 

, . . . , ,. r _ , , which is hereinafter generally described. 

FIG. 3 is a stale transition diagram for the universal „ . t . , * J . 3 , „ ,~ . , . 

dcvice Universal serial bus device controller 12 is used in the 

a « vi 1 j- a . . m m m + . present invention to generally manage the USB data 
HG. 4 is a block diagram flow chart of the data write 60 Inu,^ 

operations of the buffer, and Emission of start codes, data strobes and control and 

FIG. 5 is a block diagram flow chart of the data read data gig^ It handles most of the low level USB protocol 

operations of the buffer, operations and converts USB bit streams of data to a stream 

FIG. 6 is a high level block diagram of the parallel port of bytes, plus control and status information. It is used to 

interface m odule. 65 separate the cyclical redundancy check signal from the d ata, 

FIG. 7 is a flow chart block diagram of the parallel port while it keeps the data in a register and verifies the accuracy 

interface module; of the cyclical redundancy check signal, and is used to send 
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acknowledgment or non-acknowledgment signals to the cither being a command packet, in which cast a is trans- 
universal device controller interface 14. ferred lo block 36, and interrupt request packet which is 
Ibis is accomplished in the universal serial bus device ported to block 3$, or a data packet which is sent to block 
controller 12 by a series of blocks, not shown in the 40. 

diagrams, which include a phase lock loop for synchronizing * As shown in FIG. 3, once a transfer is initiated, universal 

the clock signals of universal serial bus device controller 12 device controller 14 transitions to a set up state as shown in 

and me entire serial to parallel port signal converter 10 to the circle 31 wherein the data from the USB host coming 

clock signals of the host, and a serial interface engine which from_univcrsal serial bus controller is loaded into an appli- 

does the initial functions of the USB protocol: syocField cation bus. The completion of the receipt of data acknowl- 

idenlificalion, NRZI-NRZ conversion, token packet to edgmenl signal (ACK) or a not-acknowledged signal 

decoding, bit stripping, bit stuffing, NRZ-NRZl conversion, (NACK) transitions universal device controller interface 14 

CRC5 checking and CRC 16 generation and checking. It back to the idle state as shown in circle 31, If the data loaded 

also converts the serial packets from the USB signal to 8 bit during the set up, shown in circle 33, is a command packet, 

parallel data. The universal serial bus device controller 12 the universal device controller interface 14 transitions to the 

also performs an additional function in the preferred CONTR0L_JN state as shown in circle 35 as the command 

embodiment, in that it stores the information about the end is decoded. And its transfer is either acknowledged or not 

points and the devices supported by the serial to parallel port acknowledged. If it is not acknowledged, the universal 

signal converter 10. device controller interface returns to idle state 3L 

The universal device controller interface is utilized as a If the data is a command packet, as shown in FIG. 2B, the 

control device for the universal serial bus device controller, 20 command packet is then decoded in block 42 and, in 

adding support for the USB protocol features not bandied decision block 44, a decision is made as to whether it is a 

directly by the universal serial bus device controller 10. valid transfer of command packet data, in this decision 

Some of these additional features include decoding of block, an acknowledgment signal (ACK) or a not acknowl- 

descriptor requests and providing of descriptor data, which edged signal (NACK) is received from the universal serial 

is sourced by the ROM 18 by way of buffer memory 16, and 25 bus device controller, either acknowledging or not acknowl- 

also provides support for all printer class device commands edging the receipt of the valid cyclical redundancy check, 

and support which is unique and specific to the present (CRC) signal. If the decision is no, the proper acknowlcdg- 

invention and not part of any standard specification. Uni- ment has not been received, then the universal device 

versal device controller interface 14 has ports for commu- controller interface resets to decision block 32 to await a 

nicaling to the buffer memory and also a port for commu- 30 valid transfer initiation. 

nicaling directly with the parallel port interface module 20. if a valid acknowledgment is received, as determined by 

Buffer memory 16 is simply that, in that it is a block decision block 44, then a decision is made as to whether or 

which has byte-oriented storage for multiple data packets, not the command signal indicates that the host device 

which in the preferred embodiment are packets of sixty four requires mat data be sent back lo the host device regarding 

bytes. There are independent input and output channels, with status information of the peripheral to which the parallel port 

buffering for two packets of 128 bytes of actual value in each interface module 20 is connected. This is also shown in the 

direction. state transition diagram of FIG. 3 as stale 37. If the answer 

Read only memory, ROM, 18 stores the specifications and is no, no status data is required, or no CX)NTROU_OUT 

information necessary to convert descriptor data from one ^ transfer is received a decision is made in decision block 48, 

communications protocol to another, as is hereinafter to send a stall handshake. If the decision is yes, and the 

described signal has been received, then in block 62 a signal of a valid 

The parallel port interface module 20 is made up of transfer is mitialed back to ^ ™rs fj^^evte 

hardware for folly automatic support of Institute of Electri- controller 12. Ift^ attwer m decision block 48 is no, that 

cal and Electronic Engineers (IEEE) 1284 standardized 45 * to say that a COOTW^JN was not expected, then in 

compatibility, NIBBLE,^tended capability port (EOT) and box 50, there is sent a staU handshake back to the umversal 

enhanced parallel port (EPP) with and without run length serial bus device controller U and the umversal device 

encoded (RLE) communications modes, and is intended to controller transitions back to idle slate shown as Circle 31 in 

emulate normal parallel port hardware, such as might be FIG. 3. 

implemented with an industry-standard super-I/O chip. It so If, as determined in decision box 46, data is required by 

also includes logic to provide control for the automatic and the host, then, in decision box 52, the universal device 

register based parallel port logic, including readable and controller interface 14 awaits for the receipt of a 

writeable registers which emulate those found in standard CONTROUJN transfer indicating that the host is ready to 

personal computers. It also includes necessary support logic receive the requested status data from the peripheral device 

such as timers, counters, digital filters and pulse stretchers, 5J as it transitions to the CONTROL_JN_statc of circle 35 of 

as is hereinafter described. FIG. 3. As shown in block 54, the data is sent to the host and 

FIGS. 2A through 2D, a flow diagram, illustrate the the universal device controller interface 14 awaits, in deed- 
actions taken in the universal device controller interface 14. sion block 56. an acknowledgment that the transfer was 
In the first step, a data input is initiated in block 30 from the received by the host. It in decision block 52, it is .determined 
universal serial bus device controller 12, after which in 60 *hat no_C0NTROL_IN transfer is received, or a 
decision block 32, a decision is made as to whether a data CONTROL^OUT transfer is received, then as shown in box 
transfer has been initiated. If no data transfer is initialed, the 50, a stall handshake is sent in the same manner as if a 
universal device controller interface continues to wail for the CONTROUJN transfer was not included in the status for a 
initiation of a transfer, as is also shown in circle 31 of state command not requiring return data or the status transfer in 
transition diagram, FIG. 3. 65 H» command was a CONTROI^OUT. 

Once a transfer is initiated, the transfer is decoded in Once the data has been sent to the host in state 39 of FIG. 

Block 34 to identify the type of data being transmitted, as 3 jnd in block 54 of FIG. 2, universal device controller 
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interface 14 awaits, in decision block 56, receipt of an embodiment, each byte of information is treated and pro- 

acknowledgmenl of the transfer. If acknowledgment is ccssed separately. If the answer in decision box 82 is yes, 

received, in block 62, the universal device controller inter- there is a location available to write a byte of information, 

face signals a valid transfer. If the transfer acknowledgment then in box 84 an ASSERT DATA-IN signal is sent to 
is notreceived, then as shown in block 60, the device signals s universal device controller interface 14 acknowledging that 

an invalid transfer lhere ^ a s P acc availaDlB " ° DCC the fi3 S Dal 15 m{ * tnea buffer 

A . . / . , „ Pnp . m * erif> *>/*» *£ memory 16 waits, at decision box 86, to receive the DATA^_ 

As shown m stele cuxle 43 of FIG. 3, and in FIG. 2C, if , N rc( ^ esl 0nce me DArA _ IN k received as 

the data identified in block 34 is an mtemipt request packet box g6 iht ^ dcscribcd in box 88 

in block 38 of FIG. 2A, a (tecision is made in decision block namc , ^ daU fe ^ft^ buficraicinor y i 6 , and 

50 whether the requested data * available. If ^ answer is 10 ^ fc ^ ^ ^ fc l0 mc ncxt 

yes^ as shown in circle 41 of FIG. 3 and then in block 52 of . ^ ^ fe / mernory and buffer memory 16 then wails for 

FIG. 2 the data s sent throng* the universal serial bus oevice ^ ^^g^nt that the transfer is completed in ded- 

conUoller 12 to the host and then awaits in dec^on btack gion te 90f ^ tf u k ^ M io ^ o 2) 

54, for an acknowledgment of receipt of the transferred data. ^ slartiDg ^ ^ fc updated to match the temporary 

If the data transfer is acknowledged, the universal device is write pointer 

controller interface thea signals that a valid transfer has } ^ CVflnt 00 Utm[tT ^w^g^t 

ocwrrcd and resets m decision block 60. If in decision block ^ g ^ DA rAJN signal, then in decision box 94 a 

50 it is determined ^at the requested data * .not available. J acknUedged (oACK) sfenal regarding receipt of the 

thenanotactoo^ DATAJN signal. After which, in box 96 the temporary 

F 1 bU& ^""^ , U kl and J 1 "™** * 20 write^okter preset to the or£nal starting value, 
the host If the requested data was available and was sent in " \ * ... ^ ^ 

box 52, and no acknowledgment is received in decision box In «vcnl n ° location is avadable foj : wnttng the byte 
54, ten as is shown in box 58, the universal device of data, then as shown in box 98, a DE_ASSERTdata input 
controller interface 14 signals an invalid transfer and the acknowledgment signal is sent. 

device resets- How data is read from buffer memory 16 is shown in the 

If the data transfer initiation identified in box 34 indicates 25 flow chart of FIG. 5. First, in decision box 100 a decision 
that it isa data packet, then in decision box 62, as shown in & made as to whether * c * ^ 

FIG. 2D, a decision is made as to whether it is a BULK_ answer is yes, then in box 102 an ASSERT DATA-OUT 

OUT packet of data from the host or a BULKLJN data request £ made, and ^^^^^JL^^!?" ^"f^ 
packet to be sent from the universal device to the host in *s to whether or not the ASSERTED DATA-OUT request 
which case universal device controller interfile* transitions 50 is acknowledged. If not, buffer memory U «uk for its 
to the BULKUDUT or the BUUQJN state shown in receipt. Once it is received then in box 106 the data is 
circles 39 and 41 of FIG. 3, as the case may be. r*rieved f™m the buffer and the temporary read pointer is 

IfuisaBUU^OUTpacket ) andfce* incremented to the next byte Afterwards, in decision box 

u u is a ja u ^f^^ ul P*™ il^Zt 108, the data out transfer acknowledgment is awaited, and 

35 upon receipt, in box HO, the starting£ad pointer is updated 
as to whether there is sufficient storage space in the buffer to 35 ^"'<^xj JiL^™™ nnmifr 
receive the data. Data packets are transferred through the to match the temporary read Tpomter. 
universal serial bus device controller 12 in eight bit bytes, * the data out transfer acknowledgment is not receive^ 
one at a time. As each byte is received, the decision is made then in decision box 112 a data out transfer is not 
concerning space availability in decision box 64. If the acknowledged, nACK, is sent and m box 114 the temporary 
decision is yes, then the data is sent to the buffer for storage, 40 rcad pointer is reset to its starting value, 
as shown in box 66. If the decision is no, a not acknowledged Id the event that data is not available for read as deier- 
handshako packet is seat as shown in box 68. Once the data mined in decision box 100, (hen a DE_ASSERT DATA_ 
is received and sent to the buffer in box 66, a decision is OUT request is made in box 116. 
made in decision box 70 as to whether an acknowledgment t 0 FIG. 6 there is shown and described a high level block 
is received for the data. If the answer is yes, then in box 72 45 diagram for the parallel port interface module 20. Al lhe 
the universal device controller interface 14 signals a valid heart of parallel port interface module 20 is controller 126, 
transfer. which is used to control, through master state machine 128, 

If the decision in decision box 62 is that the data is a compatibility mode protocol host 130, KIBBLE protocol 
BUUCJN packet which is data received from the periph- host 132 and extended capabilities part host 134. A digital 
era! for transfer to the host in response to an interrupt $Q filler 144 5 is provided for incoming signals. It is optionally 
request, then in decision box 74, a decision is made as to used to filter spurious or false signals by holding and not 
whether the data is available in the buffer. If it is not, then passing on each signal until a predetermined number of 
a not acknowledged (nACK) handshake packet is sent lo the clock ticks occur, thus assuring that all signals inputted to 
universal serial bus device 12. If the answer is yes, then in parallel port interface module 20 are true signals. Also 
box 76 lhe data is retrieved from the buffet; and in box 78 provided, as shown in the block diagram of FIG. 6 there is 
is sent lo the host, and in decision box 70 a decision is made 55 an extended parallel port register host 136 and extended 
as to whether or not ao acknowledgment is received for the capabilities port register host 138. Control registers 142 are 
data seat If the answer is yes, then in box 72 the interface provided. One shot 146 generates a fixed pulse signal to 
14 signals a valid transfer and if the answer is no, then as transition the parallel port interface module 20 output to 
shown in box 80, the signal is for an invalid transfer. high drive by generation of a fixed pulse signaL 

FIG. 4 is a flow chart showing how data is written into 60 FIGS. 7A and 7B represent a flow chart for the operations 
buffer memory 16 in response to the operation shown in ofLparallel port interface module 20, as shown in FIG. 6. 
FIG. 66 of FIG. 2D when data is sent to the buffer. The parallel port interface module 20 attempts to commu* 

As data is sent to buffer memory 16 as shown in block 66 nicate with the peripheral device in (be highest, or most 
of FIG. 2D, the first decision made in buffer memory 16 is advanced, communication protocol that the peripheral 
as shown in decision box 82 of FIG. 4. The decision made « device is capable of using. It uses a hierarchic order of the 
is whether there is a location available for writing the next IEEE 1284 communicalions protocol, starting with the most 
byte of information. In the buffer, in the preferred advanced communications protocol, and stepping down 
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through hicrarchle until it establishes communications with as to whether the data is in extended capabilities protocol 
the peripheral device. encoded without run length encoding. If the answer is yes, 

As seen in FIGS. 7A and 7B, data from the buffer 16 is then data is sent in capabilities protocol and the parallel port 
received through the parallel port interface module 20 interface module 20 will periodically try reverse in extended 
through data transfer box 151. As it is received, the first 5 capabilities protocol and NIBBLE If the decision in deci- 
decision is made in decision box 153 is whether data from box 1*1 * *o f data * »«" ™ H* conipaUbflily 

the host is available. If the answer is no. then parallel port mode and the parallel port interface moduk win periodically 
interface module 20 remains in an idle slate. If the answer to communicate with the device in NIBBLE, 
is yes, then a decision is made in decision box 155, is there In each case, whether the data is being sent in extended 
a DEVICE_ID command in the data that is available. The 10 capabilities protocol with run length encoding, or without it, 
DEVIOELJD command is the result of the translation of a or if it is being sent in compatibility mode, the parallel port 
USB command protocol entitled GET DEV1CE_JD which interface module 20 will periodically attempt to run reversed 
is the USB command protocol command which requests so as to receive dala from the device. This is shown in 
data from the peripheral regarding the identification of the decision boxes 183, 185 and 187. If the decision is yes, then 
manufacturer of the peripheral device, the type of device it to box 189 the data is sent to the buffer through transfer box 
is, and what communications protocols the peripheral sup- 15 191. 

ports. The GET DEVICE_JD command is very similar to Next, there is shown in FIG. 8 a state transition diagram 
the DEVICE_IN command of the extended communication of the operations of controller 126 of FIG. 6 for the parallel 
port communications protocol utilized by devices which are port interface module 20. As previously stated, signal con- 
compliant with IEEE 1284 specifications. As a result, as verier 10 can support three of the basic communications 
shown in FIGS. 2A through 2D, the USB GET DEVICEJD 20 protocols used with a parallel port I/O device conforming to 
command of the USB protocol is translated into a the IEEE 1284 standard. These are: the compatibility mode 
DEVICEJU) command. If the answer in decision box 155 protocol; the extended capabilities port (ECF) with or wi th- 
is yes, then in box 157 an attempt is made to send the out run length encoded (RLE) compression protocol; and the 
DEVICE_ID command to the peripheral using extended enhanced parallel port protocol (EPP). As shown in circle 
capabilities port protocols with run length encoding. A 25 150 of FIG. 8, the power up stale is idle and the parallel port 
decision has been made in decision box 159 as to whether interface module 20 is in compatibility mode. This is the 
the peripheral device communicates in extended capabilities default in which the parallel port interface module 20 will 
port protocol with run length encoding._If the answer is initially start. 

yes, then in box 169 the command, and later data, is sent in After starting in compatibility mode protocol, controller 
extended capabilities port protocol with run length ^ 126 will attempt to change states to the highest level 
encoding, and periodically a TRY_RE VERSE command is protocol available, which, in the preferred embodiment, in 
sent in extended capabilities port protocol and NIBBLE. If automatic operation is extended capabilities port (ECP) 
the answer is no, then in box 161 the parallel port interface protocol with run length encoding. If the peripheral device 
module 20 will try the DEVICE__JD command using will communicate using this protocol, controller 126 passes 
extended capabilities port protocol without run length to the forward state shown in cdrck 156 wherein the parallel 
encoding. If communication is established in extended capa- 35 port interface module 20 will communicate and pass data to 
bilities protocol as shown in decision box 163, then in box the peripheral device using extended capabilities port pro- 
171 data is then sent to the device in extended capabilities local with run length encoding. In the event that the periph- 
protocol and the parallel port interface module 20 periodi- eral device cannot communicate in this protocol, then the 
cally tries reverse communication in extcnded_cap abilities parallel port interface module 20, controller 126 will attempt 
protocol and_NlBBLE. 4° to communicate with the peripheral device utilizing the next 

If the answer in decision box 163 is no in that the device highest protocol available, which is extended capabilities 
does not use the extended capabilities communications port protocol as shown in state 154. If the peripheral device 
protocol, _then in decision box 165 a decision is made as to can communicate in this state, the machine passes into the 
whether there exists a protocol error. If the answer is yes, forward state shown in circle 156 wherein it again begins 
then data is sent as shown in box 173 in the compatibility 45 sending data to the peripheral device using extended com- 
mode and the device periodically tries NIBBLE. munications port protocol without run length encoding. If 

If the answer in decision box 165 was no, there was no the attempt to communicate using extended communications 
protocol error, then in box 167 parallel port interface module port protocol fails because the peripheral device is not 
tries the DEV1CE_JD command using NIBBLE. Inxspec- configured to communicate in that protocol, controller 126 
live of whether the device does or docs not use NIBBLE, 50 shifts into the forward slate of 156 utilizing the default 
parallel port interface module 20 will begin to send data in protocol, namely the compatibility mode protocol, 
the compatibility mode as shown in box 173 and will If in the attempts to use the higher level protocol 
periodically try NIBBLE irrespective of whether or not the languages, controller 126 for the parallel port interface 
DEVICE _JD command indicated that the device used it. module detects either that the peripheral device is not IEEE 

If it is determined in decision box 155 that the incoming « 1284 compliant, or that there is a protocol error, it will 
dm does not contain a DEVICEJD command, then in box automatically shift into the forward transmission state 
177 a decision is made as to whether the incoming data is shown in circle 156 utilizing the lowest level protocol 
enhanced capabilities protocol encoded with run length language, namely the compatibility mode, 
encoding. If the answer is yes, then the data will be sent as One of the initial command packets that will be sent by 
shown in box 169 in extended capabilities protocol with run the host device utilizing USB command protocols is the 
length encoding and parallel port interface module 20 will 60 command GET_JDEVI CE_JD which is a command which 
periodically try reverse in capabilities protocol and in requests data from the peripheral regarding the name of the 
NIBBLE. If it is determined in decision box 177 that there manufacturer of the peripheral device, the type of device it 
is no run length encoding, then in decision box 179 the is, and what communication protocols the peripheral sup- 
decision is made as to whether or not a protocol error has ports. This command is very similar to the DEVICE JD 
occurred. If the answer is yes, then the data is sent as shown 65 command utilized by devices which are compliant with 
in box 173 in the compatibility mode. If the decision in box IEEE 1284 specifications. As a result, the GET_JDEVICE_ 
179 is no, then a determination is made in decision box 181 ID command f the USB protocol is translated into a 
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DEVICEJD command. If the GET_DEVICE_JD com- ready data available, and then slate 206, wherein a byte of 

mand is received, then in parallel port interface module 20, data is retrieved. If there is more daU to be sent from the 

controller 126 will attempt lo try tbe DEVICE JD and peripheral, then the NIBBLE controller transitions back to 

command using extended capability port communications slate 204. 

protocol as shown in state circle 158. If il fails in state 158, 5 Slate 208 exists when the host is busy and data k not 

or if there is a protocol error, it will attempt again to try the available, in which case tbe NIBBLE controller transit ions 

DEVICE_JD command in the NIBBLE communication to reverse idle state 210 until il receives an interrupt from the 

protocol as shown in stale 160. If Ibis fails, the controller peripheral indicating .data Js available, u -shown in stale 212, 

shifts into forward state 156 in which case the NIBBLE controller 132 transitions back to 

If either the first attempt to communicate the DEVICE. lfl sla ^; ^ ^ f ala ™^} c ' , ^ 

ID command using ECP, (extended capabilities port) or tbe 10 WO. 12 * a state ^lUonj *W BOP controlkr 

attempt lo communicate it using the NIBBLE protocol ^ft^^J^ 

succeeds, then controller 126 passts into the stale shown in for EC F » dl ?^ U P?°J^. sta * c ? mm ^ d .' Jl 

SJSTi % ™ ^1 i Kr^^T^i^ nr^rp m S passes into tbe setup state 222 and then into the forward idle 

circle 162, namely, the receipt of the DEVK3LJD string * ^ SUtes 224 and 226 are the primary data out states 

^ om ^ P^Sfi?* 1 ^fn?^ ^ n * d for Extended Communications Protocol controller 134, 

Uon Port (ECP) or NIBBLE protocols, whichever first " Coramiinfcaljorjs Protocol controUer 134 

worked. And finally, after receiving tbe strings, controller shifls between forward idle and sending bylcs. It during tbe 

126 enters a state shown in circle 164, namely the signaling course of sending data and shifting between stales 224 and 

of tbe end of tbe DEVIOSJD transfer, and a return to tbe 226, controller 126 signals a TOY _RE VERSE command, 

default stale of 150, namely the idle state. Extended Communications Protocol controller 134 will 

During forward state operations as shown in circle 156, 20 transition through tbe forward idle state 224 to the transition 

when operating in ECP, tbe controUer will periodically issue to reverse state 230. 

a TRY_REVERSE command to shift operations into From tbe transition to reverse state 230, tbe controller 

reverse extended capabilities communications protocol, as transitions to reverse idle state 232, and then alternately 

shown in state 156. This attempt to try reverse operations transfers back and forth between reverse idle 232 and the 

occurs at a possible end of the data, or after a certain period 25 GET_J3YTE 234 slate, as data is transferred in reverse from 

of time of being in the forward state, in which case tbe tbe peripheral to the host. 

controller operates the parallel port interface module 20 in If the reverse data is run length encoded, then Extended 

reverse to pass data from the peripheral back to tbe host If Communications Protocol controller 134 transitions from 

forward state operations 156 are being conducted in corn- the GET_BYTE 234 state lo run length encoded reverse 

patibOity mode protocol, any attempt to communicate with idle state 238, from where it transitions to GETJYTE slate 

the peripheral will be done through negotiation to NIBBLE, 240, and then back to reverse idle stale 234 as the counted 

as shown in circle 168. If the attempt to negotiate to bytes are retrieved and sent 

NIBBLE as shown in 168 fails, then controller 126 reverts While the preceding describes tbe automatic mode of 

to the forward operation of state 156. In the event that the operation under which parallel port interface module 20 is 

negotiation to NIBBLE of slate 168 is successful, there will under automatic control of controUer 136, as shown in FIO. 

be NIBBLE communication from the peripheral to the host 35 g f parallel port interface module 20 is capable of being 

until the end of the data at which time the NIB_END stale transitioned into a non-automatic, register mode of 

shown in circle 170 is extended, and operations of the operation, as shown in state 172 of state transition diagram 

controller revert to the forward state 156. FIG. 8. In this mode of operation, the parallel port interface 

The master state machine 128 shown in FIG. 6, is also module is operating under direct host control. In practice, it 
shown in FIG. 9. It is the state machine that accomplishes 40 has been found to be a much slower mode of operation, but 
tbe attempt to shift modes first into extended capabilities is necessary for use with peripheral devices which use 
port protocol with run length encoded data, as shown in state additional commands and communications protocols which 
152 of FIG. 8, and if that fails, then tries to shift into are not standard to the specifications for these protocols, 
enhanced capability port protocol without run length i D register operation utilizing extended capabilities port 
encoded data, as shown in state 154 of FIG. 8, and finally 45 language, ECP register mode controller 138 is utilized. A 
into compatibility mode protocol for forward operations as slate transition diagram describing the operations of 
shown in state 156 of FIG. 8. It also accomplishes the Extended Communications Protocol register mode control- 
transitions lo negotiations to the NIBBLE protocol and the ] e r 138 is shown and disclosed in FIG. 13. Its default stale 
DEVICE _JD protocol, also as shown in FIG. 8. is idle. Upon transition of controller 126 to its register mode 

As shown in FIG. 9, tbe starling, or default state 180 is for 50 state 172 as shown in FIG. 8, and the receipt of a signal from 
operation in tbe compatibility mode protocol. Upon receipt the host to enable Extended Communications Protocol reg* 
of a start signal, the master state machine wails for if ister mode controller 138, Extended Communications Pro- 
compatibility mode protocol operations to finish in state tocol register mode operation controller 138 shifts from tbe 
182, and in state 184 will negotiate to the requested mode idle state 250 into either the forward idle stale 252 or reverse 
and upon completion of thai mode shifts to termination idle state 256, depending upon whether or not the command 
sequence shown in state 186. from the host is transitioned to either forward or not forward. 

FIG. 10 is the stale transition diagram for compatibility If the transition is to tbe forward idle slate 252, then the 
mode protocol controller 130. Its default state 190 is idled. Extended Communications Protocol register mode control- 
When enabled, it passes into a wail-for-data state 192, and ler 138 shifts between the forward idle state 252 of the send 
when output data is available, it passes into send byte state byte state 254 as long as output data is available, or until a 
194. 60 command is received from tbe host to transition from tbe 

FIG. 11 is a state transition diagram for NIBBLE con- forward idle state 252 to the reverse idle state 256. 

trollcrl32.AsshowninFIG.9,thedefauUsuie200isidle. Upon transitioning to the reverse idle state 256, the 

When controller 126 initiates NIBBLE controller 132, and Extended Communications Protocol register mode control- 

tbe peripheral has data ready, NIBBLE controller 132 Iran- ler 138 will transition to GETJtEVERSE byte stale 258, 

sitions to state 202, which is defined under IEEE 1284 « and will alternately continue transitioning between reverse 

standards as host busy data available. When the host is idle 256 and GET_RE VERSE byte stale 258 until the data 

ready, the NIBBLE controller transitions to state 204, host is transferred. 
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If, however, the reverse data is run length encoded, then 
upon transitioning to tbe GET_REVERSE byte slate 258, it 
will transition from there to run length encoded reverse idle 
stale 260, and from there to get data bytes stale 262, and then 
back to reverse idle slate 256. 

In register mode operations, parallel porl interface module 
20 is also capable of communicating with the peripheral 
using enhanced parallel port (EPP) protocols through 
enhanced parallel port register mode controller 136. FIG. 14 
discloses a state transition diagram 4 and enhanced parallel 
port register mode controller 136. Again, in this mode of 
operation, tbe parallel port interface module is under direct 
host control through controller 136, and begins in its initial 
idle state 270. Upon receipt of an enhanced parallel port 
protocol signal from the host, the enhanced parallel port 
register mode controller transitions to an idle state 272, from 
where it can transition to either send byte state 274 or GET 
byte slate 276. 

While there ts shown and described the present preferred 
embodiment of the invention, it is to be distinctly understood 
that this invention is not limited thereto but may be variously 
embodied to practice within the scope of the following 
claims. 

What is claimed is: 

1. A device connecting an external connection of a host 
device to an external connection of a peripheral device, 
comprising: 

a universal serial bus port interface adapted to receive a 
serial bit stream of data from tbe host using a Universal 
Serial Bus communications protocol; 

a controller adapted to extract data bytes from tbe serial 
bit stream of data and convert the extracted data bytes 
to comply with a IEEE 1284 communications protocol; 
and 

a parallel port interface adapted to transmit the converted 
data bytes to the peripheral device using the IEEE 1284 
communications protocol. 

2. A device according to claim 1 including: 
a memory storing a plurality of IEEE 1284 protocols in an 

hierarchical order; and 
a circuit for converting data bytes received in the Uni- 
versal Serial Bus communications protocol into data 
bytes in all of the IEEE 1284 communications proto- 
cols stored in said memory. 

3. A device according to claim 2 including a logic circuit 45 
adapted to select one of tbe plurality of IEEE 1284 com- 
munications protocols for transmitting data bytes to said 
parallel port interface. 

4. A device according to claim 1 including: 

a memory storing IEEE 1284 communications protocol 50 
information and Universal Serial Bus communications 
protocol information; and 

a circuit converting data bytes between the Universal 
Serial Bus communications protocol and the IEEE 
1284 communications protocol according to the IEEE 55 
1284 protocol information and tbe Universal Serial Bus 
communications protocol information stored in said 
memory. 

5. The device of claim 1 including: 

a serial register adapted to extract data from the serial bit 60 
stream from the host; 
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20 
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a circuit adapted to identify the data as command data, 

interrupt request data or payload data; 
a circuit adapted to convert command data from tbe 
Universal Serial Bus communications protocol into 
command dala in the IEEE 1284 communications pro- 
tocol; 

a circuit configured to convert events in tbe 1284 com- 
munications protocol into interrupt request data for tbe 
Universal Serial bus communications protocol; and 
a circuit for converting payload data from the Universal 
Serial Bus communications protocol into payload data 
in the IEEE 1284 communications protocol. 

6. A signal converter located between a host and a 
peripheral device, comprising: 

a serial interface configured to receive from the host a 
serial bit stream using a serial bus communications 
protocol; 

a circuit adapted to extract dala from the serial bit stream 

received from tbe host; 
a circuit adapted to convert the extracted data into a 

parallel data format; and 
a parallel interface configured to transmit the data con- 
verted into the parallel data format to the peripheral 
device using a parallel bus communications protocol, 
wherein the serial bus communications protocol com- 
prises a Universal Serial Bus protocol and the parallel 
bus communications protocol comprises a IEEE 1264 
parallel bus protocol. 

7. A signal converter located between a host and a 
peripheral device, comprising: 

a serial interface configured to receive from the host a 
serial bit stream using a serial bus communications 
protocol; 

a circuit adapted to extract data from the serial bit stream 

received from tbe host; 
a circuit adapted to convert the extracted data into a 

parallel data format; 
a parallel interface configured to transmit the dala con* 
verted into the parallel data format to the peripheral 
device using a parallel bus communications protocol; 
a memory storing specifications and information for the 
parallel bus communications protocol used by the 
peripheral device and tbe serial bus comniunicatibns 
protocol used by the host device; and 
a logic circuit adapted to use the stored specifications and 
information for converting data between tbe parallel 
bus communications protocol and the serial bus com- 
munications protocol. 

8. A signal converter according to claim 7 including: 
a logic circuit for determining different parallel bus com- 
munications protocols the peripheral device is capable 
of using; 

a logic circuit adapted to select one of the parallel bus 

communications protocols; and 
a logic circuit adapted to convert data bytes from the serial 
bus communications protocol to the selected one of the 
parallel bus communications protocols. 
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(57) ABSTRACT 

A RAM-based intemipt-drivcn interface device is disclosed 
for establishing a communication link between a universal 
serial bus (USB) host and a microcontroller device for 
providing a control function, the interface device being 
operative to receive digital information in the form of 
command, data and control packets from the host and to 
process the packets and communicate the processed digital 
information to the microcontroller device, and in response 
thereto, the microcontroller device being operative to com- 
municate digital information to the interface device for 
processing and transfer thereof to the host The interface 
device includes means for receiving a command generated 
by the host through a USB bus, means for storing the 
host-generated command and for generating an interface 
device interrupt signal upon storage of said host-generated 
command for use by the microcontroller device in respond- 
ing to the host-generated command, a microcontroller bus 
for transferring microcontroller information and the inter- 
face device interrupt signal between the interface device and 
the microcontroller device. The interface device further 
includes means for receiving a microcontroller command 
from the microcontroller device in response to said interface 
device interrupt signal and means for storing the microcon- 
troller command and it is operative to generate a microcon- 
troller device interrupt signal upon storage of the microcon- 
troller command for use by the interface device in 
developing an address for identification of the interface 
device to the host during subsequent communications 
therebetween, wherein daring communication between the 
host and the interface device, the interface device-developed 
address is used by the interface device to identify host- 
provided information in the form of packets, and upon 
processing of the host-provided information, to provide the 
microcontroller device with the necessary information to 
allow it to respond to the host thereby allowing a generic 
microcontroller device to be flexibly interfaced with a USB, 
host for communication therebetween. 

35 Claims, 10 Drawing Sheets 
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UNIVERSAL SERIAL BUS (USB) RAM FIG. 1 shows an example of a system using USB to 

ARCHITECTURE FOR USE WITH communicate t a host (not shown). In FIG, I, a USB host 

MICROCOMPUTERS VIA AN INTERFACE controller unit 100 is shown coupled to a PCI bus 102 for 

OPTIMIZER FOR J^G^T^ SERVICES ^^cating information through the PCI bus to other 

DEVICE NETWORK (ISDN) 5 peripheraJ dcviccS| OT bubS( 1ha t may be coupled to yet 

CROSS REFERENCE TO RELAXED further peripheral devices. In FIG. 1, the peripheral devices: 

APPLICATION phQnc device 104, a monitor device 106 and another hub 

This application is a continuation-in-part of my prior device 108 are coupled through ports to the USB host 

application Sen No. 08/846,118. filed Apr. 24, 1997, now jq c^^iier device 100. The monitor device 106 is further 

U.S. Pat. No. 5.860,021, entitled "A SINGLE CHIP coupled l0 a plurality of other peripheral devices, such as 

MICROCONTROLLER HAVING DOWN-LOADABLE ' ^ units u0 and m , a microphone device 114 and 

MEMORY ^ GAN *^^ a keyboard 116. The keyboard 116 is further coupled to a 

CHAWfEL. 1 ' All USB devices attach via a USB bub providing one or 

more ports. While each hub can provide either a high speed 
BACKGROUND OF THE INVENTION (12 m&) QX low specd {L5 mfs) support7 only lhe 

1. Field of the Invention high speed version will be considered for simplicity. Cod- 
Tnis invention relates generally to the field of general ^ nectars and line characteristics are described in the USB 

purpose microcomputers and particularly to a microcom- Specifications, and are herein incorporated by reference. In 

puter unit including a serial interface controller such as the ^ ^ferest of maximum compatibility, Intel and the USB 

Universal Serial Bus (USB) RAM device to facilitate com- impUanentors Forum make available a VHDL description of 

municalion between a host and a microcontroller. ^ Serja] j^r^ce Engine (SIE). A line driver (such as 

2. Description of the Prior Art 25 phm^ u$B translation PDI-USB-PU) uses differential 
The growth of desktop computers has been accompanied pair signaling with bit-stuffed NRZ3 (Noo-Rclurn-to-Zcro, 

by a corresponding growth in the number and types of inverted) coding. 

peripheral devices that have various connection/ . Tlon - . _r . . - „ 

r r . t ... . ■, , rw>» Every transfer across a USB interface consists or a 

interconnection schemes, eta Accordingly, today's PCs , . * . _ , _ . e . . 

havernanyperiphemlconnectors.mosto^ 30 con^maUonofpactoU F<>urc^ 

sive. As thesii and cost of the PC decreases, the relative of ™ h f P«"«* l ? ^ 

cost of these connectors increase, To alleviate this problem, Peripheral devices. Eeach transfer class will be described 

high performance serial bus schemes are being defined that briefly: 

are designed to use one connector to attach many (lower Interrupt Transfer 

performance) peripherals to the PC Furthermore, due to the 35 Useful for devices that typically interrupt the host system 

operational limitations of many of these peripheral devices in non-USB interface. USB interrupt transfers provide a 

with respect to what is referred to in the computer industry maximum latency on the order of one millisecond, with 

as "low speed", they typically require dedicated wires and average latency perhaps half that, 

connectors capable of supporting much higher speed data 40 Control Transfer 

transfers than are required. Useful for sending specific requests from the host system 

Moreover, information flows and the required responses to USB devices. This transfer is typically used during device 

over a high performance serial bus exceed the performance initialization, 

capability of generic microcontrollers of the type used in Bulk Transfer 

typical peripherals. 45 Useful for data transfers that have no immediacy or 

The Universal Serial Bus (USB) and "firewire" (IEEE periodicity requirements, such as the data returned from a 

1394) has been introduced in the computer industry to floppy disk device, 

efi^uale "time sharing" of many of these low speed periph- Isochronous Transfer 

eral devices over a single higher speed connection thereby Useful for periodic transfers or for devices requiring a 

providing higher performance communication links while 50 constant data rate, such as voice communications over an 

using such peripheral devices. This higher speed connection ISDN phone. 

requires only minimal resources (such as I/O, DMA, Inter- a transfer class is typically associated with a device 

rupt and Memory) from the host system. Prior art systems endpoint. The user of a USB device must analyze the 

require such resources per peripheral 55 transfer class(s) necessary for bis purposes, and define 

By way of background, a summary of the USB and its appropriate endpoints. The endpoints are communicated to 

operation is presented below. Although the preferred imple- the USB host controller during the configuration process, 

mentation of the serial interface bus is the USB, a similar using descriptors, which are data structures with a defined 

approach will work with the faster "firewire" (IEEE 1394) fonnal. Each descriptor begins with a byte-wide field that 

operating at 100200,400 . . . Mbits/sec. 60 covins the total number of bytes in the descriptor followed 

DESCRIPTION OF THE UNIVERSAL SERIAL by a bytewide field that identifies the descriptor type. For 

BUS endpoint descriptors, at least the following fields are 

The characteristics of a USB communication link consists required: Descriptor Length* Descriptor Endpoint Type, 
of a half duplex 12 Mbit/sec channel divided into 1.0000 ^ Endpoint address, and Endpoint attributes. An example of a 
millisecond "frames", which are distributed over a Tiered device descriptor and the descriptor communications prooe- 

Star Topology. dure is given in a following section. 
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The connection between client software on the bast 
system and an endpoinl on a peripheral device is via a Pipe. 
Typically a pipe connects the client data buffer on the host 
with an endpoint register on the device. The client software 
iniLialcs a control transfer to read the device's descriptors), 
then registers the required eodpoints with the system's USB 
host controller, which allocates USB bandwidth according to 
an implementation specific plan. 

USB bandwidth allocation is highly flexible and device 
specific. Interrupt pipes can specify a latency ranging from 
one to 255 msec. An endpoint can define a maximum packet 
size, thereby allowing the host controller/allocator to com- 
pute the number of specific eodpoints that can share a frame. 
Maximum packet size can be up to 64 for Interrupt 
endpoinls, but as large as 1023 for Isochronous eodpoints. 

USB devices are not required to have a specific number or 
type of endpoint(s). The specific configuration for each 
device is set up during initialization. Since all SETUP and 
associated packets are CONTROL transfers, then at a 
minimum, any device must have at least one control end- 
point. The USB-RAM interface described herein will sup- 
port CONTROL, INTERRUPT, ISOCHRONOUS, and 
BULK transfers, as required by the microcomputer being 
interfaced to the USB-RAM. 

CONTROL transfers begin with a setup stage containing 
an eight byte data packet, the eight bytes defining the type 
and amount of data to be transferred during the data stage. 
CONTROL transfers are guaranteed at least 10% bus allo- 
cation. In order to apportion control transfers over as many 
devices as possible, the data stage of a CONTROL transfer 
is limited to 64 bytes. Typical USB transactions consist of 
three phases: 



Pcdcci ID 

5 TRANSFER: [Sync] (SETUP] [Address] [Endpoint] [CRC-5] [EOF] 
[OUT] 
[IN] 

SOF; [Sync] [SOF J [Frame #] [CRC-5] [EOF] 
j0 DATA: [Sync] [DATA] [Data payload] [CRC-16] [HOP] 
HANDSHAKE: [Sync] [ACX ] [BOP) 

[NAJC] 

[STALL] 



15 



The USB-RAM enters a number of states in changing from 
'unattached' to 'configured' (see below). Before being reset, 
20 the powered device will not respond to the bus. After reset, 
the USB-RAM responds to requests on its default pipe using 
either a unique assigned address or the default address. 



25 



so 



35 



USB Vwfalo Device Statu 
^nnnsilioro Stale 

sol lUsched 
<Altftd» 

AtUched 
<Power> 

Powcred 
<Reset> 

Default 
<Addreu> 

Addrened 
■cCooflguro 

Configured (Ftncttoul) 



Tbfccn Dm Packst Handshake 

Phase Phase Packet Phase 



All USB transactions begin with a token phase, denning the 
type of transaction to be broadcast over the USB. The four 
USB tokens are: 

SOF (Start_of_Frame) begins each 1 ms frame 
SETUP begins each CONTROL transfer 
IN begins a data transfer torn the device to the host 
OUT begins a transaction to transfer data from the host to 
the device. 

SOF and SETUP tokens are very specific, while IN tokens 
can be used in INTERRUPT transfers, BULK transfers, 
ISOCHRONOUS transfers, and the data phase of CON- 
TROL transfers. The Token phase is always from the host to 
the device. The Data Packet direction varies according to the 
transaction, and the Handshake, if required, usually depends 
on the data direction. Each of the above packet phases 
transfers a packet with the following formal: 

[SYNC Seq.JJPacket ©packet InfolCRC-biuJEOP] 
The synchronizing sequence and End-of-Packct signal are 
bandied by the Serial Interface Engine (SIE) and are not seen 
by the microcontroller, while packet bytes (exclusive of 
CRC bits) are handled by the microcomputer device in the 
present invention, thereby allowing maximum flexibility. In 
general, USB packets look like: 



Suspended devices are maintained at a minimum power 
level, and are not functional. A USB-RAM exits the suspend 
mode when there is bus activity. The device may also request 
45 the host exit a suspend mode via electrical signaling to 
indicate a remote wakeup. 

The normal sequence begins after reset with a host read on 
50 the default pipe to determine a maximum data payload 
available on the default channel, then the host assigns an 
address. The host reads the configuration information for 
each device configuration 0 to n then assigns a configuration 
55 value to the device, causing all eodpoints to assume the 
characteristics of the configuration descriptor. 

USB devices report their attributes to the USB client 
50 software using descriptors. The format of a USB device 
descriptor is shown in FIG. 2. USB protocols define several 
descriptors: DEVICE, CONFIGURATION, INTERFACE, 
ENDPOINT, STRING, and CLASS-specific. Each of these 
^ is requested via SETUP transactions in which the desired 
descriptor type is requested from the microcomputer. The 
preferred implementation uses the following procedure: 
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// < pipe > < Host > — 

pipe-COHTROL< SETUP >— > 



UfiB >- 



< u c > — 



< DMSAO >- 
< — — 



S — < pi >- 



V- 



: HAK > 



< DI > 



-< Int j*C > — 



|iC sees Std Der ReQ 
r*ads 8 byte©, than 
writeB to noaory and 

camnands USB device 



-< KAX > 



I / 

-< X3ATA1 > 



< ~< mt U6B >- 



ACK > — 



The genera] description of the USB scheme and prior art class of microcontrollers such as the Intel 8051, the 

USB interfaces has been presented above. A time multi- 25 Motorola 68xx, the Micron PIC, and similar 8-bit micro- 

plexed medium speed serial bus is used to handle multiple controllers (also 4 and 16-bit), which typically do sot 

low to medium speed devices, using multiple transfer types. include DMA circuitry, but do support memory interface and 

At reset time the device must respond to packets on the external interrupts). 

default CONTROL pipe at address zero. Initial responses jfa transfer of data between the high performance serial 

result in the device being assigned a unique address and in 30 bus anc j a ^ performance generic microcontroller occurs 

the device communicating descriptor information describing v i a memory buffers that have specific locations and sizes, 

the number and types of endpoinls that must be configured fh c locations and sizes will generally be specified by the 

for the application that the device is serving. These and all microcontroller; and this information will be used during 

following transfers are initiated by the USB host, typically transfers, by the serial interface device, Because of the 

via an IN or an out token, where the direction of information, 35 asynchronous relation between the serial bus and the 

i.e. IN and OUT, is relative to the host The microcontroller microcontroller, arbitrating access to such buffer informa- 

tben sends or receives a DATApackel as appropriate. Details ^ problematic 

of the present invention are described below. Therefore, the need arises for an inexpensive device to 

As shown in FIG. 3, there are several approaches for interface peripheral devices, of various different types, such 

establishing communications between peripheral devices 40 ^ currently-available microcontrollers, with a host through 

and a host through the USB. One such approach at 122 is the tne or omcr ous devices while taking advantage of the 

USB-to-clocked serial interface, which uses the high speed of the bus device, 
commercially-available Tbesys TH6503 device. Another 

approach, shown in FIG. 3 at 124, is a USB-to-FIFO design SUMMARY OF TOE INVENTION 

using the NetChip NET-2888. A third approach, shown at 45 • 

126\ is to embed the USB device in a micro-controller, either Accordingly, it is an objection of the present invention to 

an 8051 derivation such as the Intel 8x931, the Siemens Provide a Serial Interface Controller that uses buffisnng via 

C540U & C541U, the Anchor Chips EZ-USB, or the a memory-based interface capable of generating interrupt 

Cypress CY7C63001 signals to the generic microcontroller, and of coordinating 

While the first approach, USB-to-clocked serial interface, so data transfers between the host and the microcontroller, 

is simple and useful for RS-232-like devices, it embodies all including flow control, and error handling and retry mecba- 

of the limitations of the RS-232-fflce serial devices. For nisms - 

example, RS232 on IBM PC's are (1) typically slow The present invention represents a new architectural 

devices; (2) not well suited to multi-channel architectures; approach to solving the problems mentioned above. The 

and (3) require considerable processor resources. The sec- 55 invention provides a method and apparatus for providing a 

ond approach is more useful forfaster transfers, but typically high performance serial interface between any 

requires DMA I/O to allow the controlling device to service commercially-available microcontroller device and the USB 

the FIFO as required. The final approach, the USB embed- or other high performance serial bus. The architecture used 

ded in a micro-controller, is well suited for hi-volume in the presently preferred embodiment of the present inven- 

applications (Cypress details "mouse controller'* 60 tion (hereinafter referred to variously as the Serial Interface 

application) but represents an extreme amount of design Ram (SI-RAM) or USB -RAM architecture) is related to the 

work (with minimal tools) for low to moderate volume single chip processor unit design described in Applicants' 

applications. pending U.S. patent application Ser. No. 08/846,118 filed 

The approaches presented above for interfacing with the Apr. 24, 1997 and entitled "A SINGLE CHIP MICRO CO N- 

USB have a number of shortcomings. One such shortcoming 65 TROLLER HAVING DOWN-LOADABLE MEMORY 

is that a very significant design effort is required, anotheris ORGANIZATION SUPPORTING "SHADOW" 

that these approaches are incompatible with a very large PERSONALITY, OPTIMIZED FOR BI-DIRECTIONAL 
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DATA TRANSFERS OVER A COMMUNICATION FIG. 4 illustrates a preferred embodiment of the present 

CHANNEL". The application disclosure is expressly incor- invention to include a USB host coupled, through a com- 

porated herein by reference. mum'cation link, to a USB RAM device 130 

An important advantage of the present invention is that it FIG. 5 shows a detailed view of the internal architecture 
provides a high performance interface device for coupling a 5 0 f the USB RAM device shown in FIG. 4. 
commercially-available microcontroller to the USB or other pig. 6 shows a more detailed schematic of the sub- 
high performance serial bus for communication therebe- structure in FIG. 5. 

tween. The interface provides for rapid communication nG ? dwws mc organi!tatioQ Q f aD endpoint register 

between the microcontroller and the serial bus device. ^ endpaint register file 193 of FIG. 5. 

Another advantage of the present invention is that the >° Q g shows h{cdadn 1o M endpoint n ^ 

interface appears to the microcontroller as a RAM device . . . t . AmfmnU 

having inTrrupt capability thereby allowing any HO. 9 shows a memory map, which is the defauh 

commerrialiy^vi^ ™*<*y n^P (or organization) of information stored in the 

USB 7 dual port RAM device. 

Yet another advantage of the present invention is that it 15 . FIG. 10 storage loca- 

provides a general purpose USB-to-uC interface that is also «on is shown included within the endpoint register file, 

optimal for interfacing to an ISDN adapter. FIG. 11 shows a Bulk-Out endpoint register storage 

Briefly, a preferred embodiment of the present invention location is shown included within the endpoint register file, 

includes a RAM-basecd interrupt-driven interface device for ^ FIG. 12 shows the default INTERRUPT endpoint register 

establishing a communication link between a universal serial of the endpoint register file. 

bus (USB) host and a microcontroller device for providing FIG. 13 shows the configuration of the default ISO-IN 

a control function, the interface device being operative to endpoint register of the endpoint register file, 

receive digital information in the form of command, data piG. 14 shows the configuration of the ISO-OUT end 

and control packets from the host and to process the packets ^ p 0 int register 356. 

and communicate the processed digital information to the Q 1$ sbows ^^^i representation of control 
microcontroller device, and in response thereto, the micro- 

controller device being operative to communicate digital * ,„ A ... , , . . 

fer thereof to the host, The interface device inclides means „ ™W * tcrfaces: a USB lDtcrf * ce m ** n ISDN ^^- 

for receiving a command generated by the host through a FIG. 17 shows the layered architecture of ISDN as 

USB bus, means for storing the host-generated command supported by the present invention, 

and for generating an interface device interrupt signal upon DETAILED DESCRIPTION OF THE 

storage of said host^enerated command for use by the PREFERRED EMBODIMENTS 
microcontroller device in responding to the host-generated 35 

command, a microcontroller bus for transferring microcon- In FIG. 4, a preferred embodiment of the present inven- 
troller information and the interface device interrupt signal don is shown to include a USB host 128 coupled, through a 
between the interface device and the microcontroller device. communication link 148, to a USB RAM device 130. The 
The interface device further includes means for receiving a USB RAM device 130 is further coupled to a microcontrol- 
microconirDller command from the microcontroller device ^ ler device 140 via microcontroller lines 216. The USB RAM 
in response to said interface device interrupt signal and device 130 includes a request storage location 142, a corn- 
means for storing the microcontroller command and it is mand storage location 144 and an address storage location 
operative to generate a microcontroller device interrupt 146. As will be further described below, storage locations 
signal upon storage of the microcontroller command for use 142 and 144 reside within a random-access-memory (RAM) 
by the interface device in developing an address for idenli- 45 device while the storage location 146 is included in a 
fication of the interface device to the host during subsequent register. 

communications therebetween, wherein during communica- The request storage location 142 operates to store cona- 
tion between the host and the interface device, the interface mands provided by the USB host 128 for use by the 
device-developed address is used by the interface device to microcontroller device 140. The command storage location 
identify host-provided information in the form of packets, 5Q 144 operates to store a microcontroller-provided command, 
and upon processing of the host-provided information, to which ultimately provides an address in the address storage 
provide the microcontroller device with the necessary infor- location 146 of the USB RAM device 130* The USB RAM 
malion to allow it to respond to the host thereby allowing a device 130 is assigned an address by the USB host 128. This 
generic microcontroller device to be flexibly interfaced with process is performed by the USB host 128 initiating an 
a USB host for communication therebetween. 55 address configuration procedure. During such a configura- 

These and other advantages of the present invention will lion process, the USB RAM device 130 is assigned a unique 

no doubt become apparent to those skilled in the art after address that it uses for detecting its identity among other 

having read the following disclosure which makes reference USB devices which may also be coupled to communicate 

to the several figures of the drawing. with the USB host. 

IN thp DRAWINGS 60 Rescttin B of the USB RAM device 130 will invoke the 

IN Xrl£ DKAWiiNLo device to respond to a default address of zero. It should be 

FIG. 1 is a diagram illustrating an example of a system noted that each device that is coupled to the USB host 128, 

using USB to communicate to a host other than the USB RAM 130, is also assigned a unique 

FIG. 2 presents the format of a USB device descriptor. address prior to transfer of any information. 

FIG. 3 showB several approaches for establishing com- 65 A M SET_j\DDRESS" request is used to assign the USB 

munications between peripheral devices and a host through RAM device 130 its unique address. The microcontroller 

the USB. device 140 is responsible for interpreting the "SET__ 
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ADDRESS", request which is transpareol to the USB RAM coupled to receive information from a receiver comparator 
device 130* The USB RAM device 130 delects a "SETUP circuit 164 which is in turn coupled to receive information 
PID" (Packet Identification), i.e. SETUP|0 with PID being from the receiver CRC circuit 160. 
the value '0', command, and signals the microcontroller As described earlier in this document, typical USB trans- 
device 140 when the device request has been received and 5 actions consist of three phases: a token phase; a data packet 
stored via the request storage location 142 from the USB phase; and a handshake packet phase. Each of these packet 
host 128. The microcontroller device 140 determines that the phases is arranged in a given format having a sync, a packet 
request stored within the request storage location 142 signals jj) 9 packet information, CRC information, and EOL infor- 
the device address assignment by decoding the "SETUP ma iion (the latter for identifying when the communications 
PID" and thereafter wriies a SET_ J ADDRESS command to 10 is going to be idle). Accordingly, when information is 
the USB RAM device 130 by storing (he command in the received through the communication link 148, the sync 
command storage location 144 and storing the address at a portion of the packet is detected by circuit 158 and the CRC 
specified location in RAM. The USB RAM device 130 then portion of ibe packet is delected by the circuit 160. The CRC 
copies the address information into the address storage portion of the packet is compared, using the circuit 164, to 
location 146. 15 a generated CRC, which is developed by the circuit 166. The 

FIO. 4 generally illustrates the basic communication outcome of this comparison is a generated signal, by the 

protocol between the USB RAM device 130 and the micro- circuit 164 and coupled onto a CRC OK line 172 such that 

controller 140 when a SETUP command is initiated by the when the two CRC values match, the signal that is coupled 

USB host 128. The internal architecture within the USB onto the CRC OK line 172 is activated. The sync detector 

RAM device 130 is then used to facilitate the command *° line 170 and the CRC OK line 172 are further used to 

protocol as will be described in further detail below. provide coupling between the serial interface engine 

It should be further noted that the communicatioos pro- receiver 154 to and a USB-RAM timing and control circuit 

tocol between the USB RAM device 130 and the USB host 174. The detailed design of the tuning and control circuit 

128 is governed by the USB specification, which is a known 174 is described in the form of 'pseudocode' in Appendix 

standard in the industry and is described in a publication 25 A attached hereto. 

entitled "Universal Serial Bus System Architecture* by Don During transmission of data from the USB RAM device 
Anderson. Data that is communicated via the communica- to the USB host, the serial interface engine transmitter 
tion link 148 between the USB host and the USB RAM transfers serial data via the transmitter line 152. The serial 
device is performed in a serial fashion in the form of packets. interface engine transmitter 156 includes a transmitter sync 
FIG. 5 is presented to show a detailed view of the internal 30 circuit 169 coupled to the transmitter line 152 for developing 
architecture of the USB RAM device 130. In FIG. 5, the the sync portion of a packet The serial interface engine 
communication link 148 is shown as a full duplex commu- transmitter 156 further includes a transmitter CRC circuit 
nication link having D+ and D- lines coupled to transfer 171 coupled to receive data from the internal data bus 168 
information between the USB host 128 (not shown) and a . and coupled to generate a CRC bit pattern onto the trans- 
receiver line 150 and transmittal line 152. That is, the mitter line 152. The serial interface engine transmitter 
communication link 148 couples information received from farther includes a transmitter bit stuffing circuit 173 which 
the USB host serially onto the receiver line 150 and similarly is coupled to the internal data bus 168 and further coupled 
transfers information from the serial transmitter line 152 to the transmitter line 152. 

through the communication link 148 to the USB host. ^ A Packet notification (PID) decoder circuit 176 is 

The receiver line 150 is shown coupled to a serial inter- connected to the internal data bus 168 for decoding packet 

face engine receiver 154 and the transmittal line 152 is identification information from each formatted packet 

shown coupled to a serial interface engine transmitter 156. received and accordingly generates control signals that are 

The design and VHDL specifications for the serial interface coupled onto a PID control bus 178 for use by components 

engine receiver 154 and the serial interface engine transmit- 45 of the USB RAM device. 

ter 156 are commercially made available to users by Iotel In FIG 5, additionally shown, is an address register 180 

Corporation. that is coupled to the internal data bus 168 for receiving 

The serial interface engine receiver 154 operates to con- address (or identification) information from the USB host, 

vert received serial data from a nonreturn-to-zero (NRZ) The address register 180 stores the received address infor- 

fonnat to a binary format for use by the USB RAM device 50 mau'on and couples the same onto an address bus 186 for use 

130 and the serial interface engine transmitter 156 similarly by an address comparator circuit 184. The address register 

converts serial binary data to NRZ, data for communication 180 operated to store a new address upon activation of a 

to the USB host signal that is coupled onto an address latch line 182 by the 

Included in the serial interface receiver 154 is a receiver circuit 174. The address comparator circuit 184 compares 

sync detector circuit 158 coupled to receive serial informa- 55 toe address information that is stored in the address register 

tion from the receiver line 150 and operates to generate a 180 to the address information that is stored in the address 

sync detect signal that is coupled onto a sync detector line storage location 146 and generates a signal in response 

170. The serial interface engine receiver 154 further includes thereto that is coupled onto an address match line 195. 

a receiver CRC circuit 160 coupled to the receive line 150. The address storage location 146 is further coupled to an 

Further included within the serial interface engine receiver 60 endpoint register file 198 and to the circuit 174 through a 

154 is a receiver bit stuffing circuit 165 coupled to the timing and control address bus 192. The address latch line 

receiver line 150 for removing bits that are included in a 182 and the address match line 195 are connected to the 

received packet that are neither sync nor CRC bits and circuit 174. The device address latch line 194 is also 

provide no valuable information to warrant decoding connected to the circuit 174. The circuit 174 is further 

thereof The receiver bit shining circuit 165 is connected to 65 connected to a timing and control bus 220 and generates 

the an internal data bus 168 and it is further coupled to a signals coupled onto two busses: the endpoint register file 
receiver CRC generator circuit 166. The circuit 166 is control bus 204; and the working pointer control bus 222. 
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The circuit 174 further generates and receives signals virtual endpoinl register file storage location 248 which is 
through a dual port RAM control bus 218. The circuit 174 mapped from address locations 0x7C0 to 0x780. The device 
consists of hardware components and executes a program 214 further includes a SETUP storage locatioo 250 for 
for generally arbitrating the flow £ information among the storing the SETUP control information as discussed earlier, 
remainbg components witto^ s The dual port RAM device 214 further irwludes an ISO OUT 

so doing, the circuit 174 generates and receives control fata storage location 252 and an ISO IN data storage 
informal used to direct information traffic through the Ration 254. Hie location 252 is used to store data when 
dftv'ce 130 daU * oein 6 tra nsfe rred from the USB host to the micro- 

controller device 140 and the location 254 is used to store 

The endpoinl register file 198 is coupled to receive daU i^^^n when data is transferred from the micro- 
information from an endpoint control bus 202. The endpoinl " com roller 140 to the USB host 128. 
control bus 202 communicates information from an endpoinl Sterna! data bus 168 is toner coupled to a trans- 

decoder cinnut200 which is in turn coupled to the internal infonnation generator circuit 224. which iscoupled to 

data bus 168. The endpoint register file 198 is operative to ^ 1?4 through lran6mittef gCDCralor mM bus 

generate information mrcu^ a wrtong pointer bus 208 to 226. The circuit 224 includes a DATA0 generator circuit 228 
a working pointer circuit 206 Tbe working pointer 206 is " wMch ^ lcd t0 outpul l0 ^ mlemal ^ ^ 16S and 
further coupled to the internal daU bus 168. Hie endpoint M ^ (he dicuit m lhft) h ^ ^ 226. The 

register file 198 is comprised of endpoint registers wUh each cirCQi , 23%^ ^des a DATA1 generator circuit 230, 
register for storing information that pertains to ^ endpoint an ACK generator circuit 232, a NAK generator circuit 234, 
The ^ contents of the endpomt register file 198 will be further ^ and a st^Ll generator circuit 236 which arc all coupled to 
explained below. we internal data bus 168 and further coupled to the circuit 

The working pointer circuit 206 is coupled to a dual port 174 through the bus 226. Information from the circuit 224 is 
RAM device 214 through an internal address bus 210 that is received through the internal data bus 168 by the transmitter 
generated by the working pointer circuit 206. The dual port 15$ ao d converted to NRZ format for transmission to the 
RAM device 214 is coupled to: circuit 174 through tbe bus ugg 

218; endpoint register file 198 through an endpoint address Pursuant to the USB serial protocol data transferred via 
pointer 212; and internal data bus 168. The dual port RAM packcts ^ either read from or written to the USB RAM 

device 214 is further coupled the nucrocontroller device 140 dcvicc m As will be apparent further below, when written 
through microcontroller lines 216. The microcontroller lines to> lbc ^ u ^ RAM locations in the dual port RAM 
216 include an address bus, a data bus and control lines, the dcvicc 214 cause respective interrupt signals to be asserted 
latter for coupling chip select, read, write, ALE and INT ^ wheD Md from the RAM locations, cause the respective 
signals therethrough. interrupt signals to be cleared. Access to these locations, 

Data is transferred between the USB RAM device 130 and, typically, access to associated data in RAM requires the 
and the microcontroller device 140 through the iisc of a working pomter on either sifo 
bi-directional data bus of the lines 216. The read and write ^ i Ctf me address bus 212 on one side and the address portion 
signals coupled onto die lines 216 identify the direction of 0 f the bus 216 on the microcontroller side. The preferred 
data flow between the USB RAM device 130 and the implementation utilizes a working pointer per end point in 
microcontroller device 140. The ALE signal is used for 198, although by the nature of the time shared bus, only one 
accommodating 8 and 16-bit addressing schemes. For pointer is active at a time. In addition, a separate pointer 206 
example, if the address bus included within lines 216 is 16 ^ & dedicated to service interrupts, 
bits wide, the 8 most significant bits of tbe address lines are Handshake responses to USB packets must occur in 
first captured in a latch or register device (not shown) using approximately one microsecond. Even with interrupts, this is 
tbe ALE signal by the USB RAM device 130 before arrival considerably faster than typical microcomputers can 
of tbe 8 least significant bits at which time, bom portions of respond, therefore the architecture must compensate for this 
the address are concatenated to form a 16 bit address 4$ mismatch. The preferred compensation implementation 
information for use in reading and writing data in the USB employ the use of •auto-NAK* wherever feasible, and the 
RAM device 130. use of "pre- configuration." For example, only one pipe at a 

The dual port RAM device 214 is a sophisticated storage time can be active, therefore, in principle one working 
device having an associated memory map that is particularly pointer will suffice to read and write packets in the USB 
suited for USB applications. The memory map associated J0 RAM 130. However, if the microcomputer cannot respond 
with the dual port RAM device 214 includes the request fast enough to setup the pointer for each pipe, then the 
storage location 142 which is mapped to the top of the pointer would have to point to the same default memory 
memory at a location identified by '0x7FF' (in hexadecimal location for all pipes. But this then requires the microcom- 
notation). When the request storage location 142 is puter to load and unload each data packet quickly and to free 
addressed and written to, an interrupt is generated to the 55 up the memory for the next transaction. In general, this is not 
nucrocontroller device 140 through the INT signal that is practical, therefore we use the "pre- configure* strategy: each 
coupled onto the lines 216. endpoint has an associated virtual endpoint register, within 

The dual port RAM device 214 further includes the the virtual endpoint register file storage location 248 of the 
command storage location 144 which is mapped to address dual port RAM device 214, identified within the device 214 
location 0x7FE. When ibe command storage location 144 is 60 by a pre-assigned address per each endpoint register. Using 
written to by the nucrocontroller device 140, an interrupt is this address, each endpoint register may be pre-loaded 
generated and received by the circuit 174 through the during reset by the microcontroller device 140. 
interrupt line of the control bus 218. Tbe dual port RAM Because different endpoints may have different maximum 
device 214 further includes a mailbox storage location 240 packet sizes associated with them, it is convenient to asso- 
and IK-PAGE storage location 242 and an OUT-PAGE 65 ciale these values with tbe pointer registers, so that, at tbe 
storage 244. Further included within the device 214 is an same time the working pointer in 198 is loaded with a 
area for storing virtual endpoint register information at a specific endpoint, the corresponding counter is also loaded: 
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Thus the microcontroller device 140 can preload the following 3 biu identify which endpointlype is being stored, 

counters and address registers of the virtual endpoint register i.e., control ISO-IN, ISO-OUT, etc. The next bit distin- 

file 248 thai is associated with each endpoint with unique guisbes between a NACK and an ACK packet and the next 

values when the USB RAM device 130 is in reset These 5 bite are the packet count; the next bit 22, identifies whether 

defaultv»luescanbechosentooplimi2e,insomesense,lhe s there is a DATA 1 versus DATAO ^type >of infonnaUon. The 

distribution of end point buffers over the dual port RAM "J"*/* ■«» ^ ' ■ b * » "jfS c,,e lJf 

device 214. While optimal fcr a "typical" system, such check and the next 8^15.^1824 through 31 are byte counter 

values are almost never ideal for various particular systems. ™*- 

Thus, the pmgrammability of the registers and counters u Each of the 32-bit enopoint registers 259 has an image id 

assodated with endperints. aUows for the 'best' distribution to *• ual storage locabon 248 withm the dual port RAM 

of endpoint buffers for any given application thereby maxi- 214 m ™- 5 - The virtual storage tocation 248 holds 

mizinfr flexibflitv the endpoint register information and this information is 

mmng u y. ] 0& ded into the endpoint register file 198 when the USB 

Each of cuxuus 232,^ and 236 rcspecUvdy gen- ^ dev|ce fc „ discussed lbove . ^ 

erate the ACK, NAK and STALL handshake packets dis- fidd fc ^.fter selectively re-loaded, as appropriate. Each 

cussedearbetWilbeachoftb^^ « rf ^ ^ of m Mdpoinl regisler nG. 7 U further 

to the packet information before transrmssion thereof to the desoribed M ^ Byle Counl6I 

USB host («tt » ac being necessary to Iransm.t). 24 through 31. endpoint byle counter field 

However, an EOP which basically has the effect of causing ^ ta ^ ^ eDdpobl bylc 

0* commumc*»n bne to become idle is transmitted L Tta counlcr 256 (shown in FIG. 6).The P natureo£theUSB packet 

circuits 228 and 230 operate to couple data information onto zu , v . , , ' , , , ^ 

" . ™ , ™ " ^ K-o , - , ^ . . protocol ensures thai only one packet will be on the bus at 

the internal data bus 16ft far transmission thereof through p . .. . . ' ^ Jrz ^^^uu Ti^fi™. 

. A rrro ■ , any Given time and packets are not pre-cmpuaole. rbereiore, 

the circuit transmitter 156 to the USB host. , 7 °t . . r , . r , r _ - 

iiaiwuji^i w ui ^ device requires one byte counter regardless of the 

The endpoint decoder circuit 200 is a 1 to 16 decoder and DUmbcr of cadpoint registers implemented, 

the endpoint register file 198 which works in combination Whcn ^ jm token on a specified endpoint is received, the 

with the endpoint decoder 200 is not simply a register file, fa coumcr256is baded ^ the byte count value for that 

but rather a sophisticated device for storing endpoint register s L dfic cndpoinl> and ^ counter is used to count down 

information in an elaborate fashion, as will be described b^^n^ted to the USB host by the USB RAM device 

further below. 130, terminating the packet when the counter reaches zero. 

Trie PID decoder circuit 176 as described above, decodes 30 v/hcn an OUT !oken fc rcce i V ed by the USB RAM device 

the packet ID information and based upon the information ^ lbc byte counter 256 is zeroed and may be used to count 

included within the packet ID generates control signals to up ^ of byles scnl from the USB host to the USB 

the circuit 174 via the bus 178. The packet ID, and may be devicc 130( The output of the counter is coupled onto 

any one of SETUP, OUT, IN, SOF, DATA, ACK, NAK me inlernal data ^ lfi8 (shown m m0r g) ^ mal lhe byte 

information and based upon such information control lines ^ may be bitten to the dual port RAM device 214 

such as delineated within bus 220 generated by the packet wheD reouired. 

decoder circuit 176. Further generated by the packet decoder Endboint Packet Counter 

circuit 176 is a PID error signal coupled through the bus 178 For cach cndpoml register, there is a packet counter field 

to the bus 220 for receipt by the circuit 174. This signal is 258 stored ^ register file 198. The packet counter 

used to detect a packet io^ntificatfon iriformaUon has been ^ field ^ aclua ]jy implemented as a bit up/down binary 

received in error. The internal data bus 168 is 8 bits wide, counter. During nor mal operation, the packet counter for 

while the internal address bus(es) 210012) are at least 11 particular endpoint is pre-loaded with the appropriate packet 

bits wide. As each endpoint is communicated from the USB C0Uflt dependmg upon which endpoint is being processed 

host to the USB RAM device 130 using descriptors, the field and C0UDted downi & each packet is sent to the USB host, 

of the descriptor is used to select the appropriate endpoint 4J §£Q 

register within the endpoint register file 198. Each of the ^ sequence bit which is shown in FIG. 7 as being in bit 

registers within the register file 198 serves an endpoint such position 22 is also stored per endpoint register and its bit 

as CONTROIL, ISO-OUT, ISO-IN, INTERRUPT, BULK. ^ ^0^^ between DATA0 and DATA1. The bit is 

Each field of the descriptor stored within the regisler file 198 ^ by a^uit when loaded and it is toggled in place when 

has a formal as shown in FIG. 7. 50 ^e appropriate condition occurs, this bit is used to set 

In FIG. 6, a more detailed schematic is shown of the outgoing data PID and to test incoming data PID* 6. 

structure in FIG. 5 that handles most of the endpoint Endpoint Enable Bit 

information. The endpoint regisler file 198 is shown to Each endpoint register 259 in the endpoint register file 

include rows of storage locations, each row for storing an 198 shown in FIG. 5 has associated with it an endpoint 

endpoint register 259. Each endpoint register 259 is 32 55 enable regisler bit 264 that is 'zero' by default This enable 

("0 ... 31) bits wide and these bits arc grouped into fields bit is loaded from the corresponding virtual endpoint register 

as will be described further with respect to FIG. 7. A byte storage location 248 within the dual port RAM device 214 

counter 256 is shown included within the byte counter field and is therefore set by the microcontroller device 140 and 

of each of the endpoint registers 259 although as indicated reset by the USB RAM device 130. 

earlier, only one byte counter is necessary for all endpoints. M Endpoint Type Field 

Toe type of ENDPT field 266 tells 174 what type of endpoint The endpoint type field 266 is 3 bits wide and specifies the 

is being serviced. type of endpoint that the endpoint register has been assigned. 

Each row of the register file 198 in FIG. 5 contains 32 bits lhe default values are implementation specific but at least 
as shown by a representative row in FIG. 7. In FIG. 7, one endpoint register must always be dedicated to the 
starting from the least significant bit, 8 bits (0 ... 7) are 65 default control pipe. Beyond this, there are very few con- 
designated for the storage of the index information. The next straints on endpoint register assignments and the "interface" 
3 bits, bits 8 through 10 identify the page number. The or endpoint register assignment is under the control of the 
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USB RAM device 130 and should match the relevant 
descriptor. This feature allows a broad flexibility in USB 
interfaces. The eodpoint type field is read by the USB RAM 
timing and control circuit 174 in order to determine the 
appropriate behavior Cor toe endpoint The USB host pre- 5 
sumably is aware of the endpoint configuration and thus 
provides appropriate tokens for such configuration. 
Page and Index Pointer Register Field 

The page and index pointer register field 268 comprises 
the remaining 11 bits of each endpoint register and it is 10 
dynamically implemented as a pre-Ioadable binary up/down 
counter which serves primarily to access data bytes within 
the dual port RAM device 214 when packets are sent or 
received by and from the USB RAM device 130. Typically, 
this pointer field "page plus index" operates as an 11 bit is 
address register, however some implementations will find it 
convenient to preserve the page value and to "wrap" the 
index instead of "carry*' the same into the page. Thus, the 
preferred implementation provides an option to support 
either of tbesc paging methods. This 11 bit pointer register 20 
field contains the address of a data buffer within the dual port 
RAM device 214 that is used for data transfer between the 
USB host and USB RAM device. Validity Bit 

The validity bit 270 is required by the serial interface 
engines 156 and 154 to determine that a specific endpoint 25 
register is valid or not. The microcontroller device 140 does 
not necessarily use all available USB RAM endpoints. For 
example, there may be some USB RAM specified endpoints 
such as the "bulk" thai may not ever be used by the 
microcontroller device and therefore receipt of such an 30 
endpoint would be an invalid situation determined by testing 
the validity bit 270. 

It should be noted that each of the endpoint register fields 
are loadable from the internal data bus 168 shown in FIG. 5. 

In FIG. 8, an endpoint register is shown from among the 35 
endpoint registers in the endpoint register file 198 of FIG. 5 
to show further details of the coupling of each of the 
endpoint registers to the data bus 168. As shown in FIG. 8, 
an endpoint register 259 is shown coupled to the internal 
data bus 168 for transfer of bi-directional information in 40 
terms of loading or programming of the endpoint register as 
well as providing contents of the register. The endpoint 
register 259 is further capable of being loaded with default 
values through lines 274 at a time when the USB RAM 
device 130 is being reset and upon certain conditions 45 
occurring. However, default values loaded into the endpoint 
register can be overwritten and the register can be reloaded 
at anytime before using the contents of the register. 

With respect to the fields in each endpoint register as 
described in FIG. 7, the endpoint byte counter 256 and the 50 
endpoint packet counter 256, as well as the page and index 
register 268 are all preloadable fields that have up/down 
counting capability. That is, the byte counter, packet counter 
and page and index pointer fields are reloadable up/down 
counters. 55 
The Virtual Endpoint Register File 

Referring back to FIG. 5, the endpoint register file 198 is 
not directly accessible to the microcontroller device 140. 
Instead, the virtual endpoint register file storage location 248 
within the dual port RAM device 214 stores a file of virtual 60 
endpoint registers that is directly accessible to the micro- 
controller device 140. 

When the client software has chosen a specific configu- 
ration of endpoint registers from the configuration descriptor 
or other descriptors, the microcontroller device 140 must 65 
write the appropriate information into the virtual endpoint 
register file storage location 248 and then command the USB 
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RAM device 130 to copy that information into the endpoint 
register file 198. After copying the register information, the 
USB RAM device 130 is configured and functional. 

Because the virtual endpoint register and other registers in 
the dual port RAM device 214 must be accessible by the 
USB RAM device 130, an address pointer, stored in the page 
and index pointer register 268 (shown in FIG. 6), is coupled 
onto the address pointer bus 212 for accessing data from the 
dual port RAM device 214 and placing it onto the internal 
data bus 168, is provided. 

As earlier discussed, the microcontroller device 140 is 
capable of loading data into the virtual endpoint register file 
storage location 248 for subsequent use by the USB RAM 
device 130 upon transfer of the data to the endpoint register 
file 198. 

The procedure for the microcontroller device 140 loading 
data into an endpoint register within the eodpoint register 
file 198 is as follows: 

1. The microcontroller device 140 loads data into one or 
more of the register storage locations to the virtual 
endpoint register file storage location 248 within the 
dual port RAM device 214. 

2. The microcontroller device 140 then issues a command 
to the USB RAM device 130 by writing into the 
command register 144 at address 0x7FE the command 
value that will be interpreted as "Load EndPt Reg File."* 

3. The Timing and Counter unit 174 the USB RAM device 
130 decodes the command, and, if appropriate, stores 
the low byte portion of the address of the register 
storage location of the virtual endpoint register file 
storage location 248 (loaded in step 1. hereinabove) 
into the working pointer circuit 206. 

4. The USB RAM device 130 couples the contents of the 
page and index pointer register 268 onto the address 
pointer bus 212 and reads the low byte address portion 
referred to in step 3. 

5. The low byte portion, read by the USB RAM device 
130 in step 4„ and addressed by the working pointer 
circuit 206 is transferred via the internal data bus 168 
and latched into the (selected) endpoint register within 
the endpoint register file 198. 

6. The procedure is repealed in a similar manner as 
described above for the middle and high bytes of the 
address of the register storage location of the virtual 
eodpoint register file storage location 248 (loaded in 
step 1. hereinabove) by incrementing the working 
pointer circuit 206 and repeating steps 4 and 5 for each 
of the middle and high byte portions. 

Error Retry 

During the normal course of operation of the USB RAM 
device 130, the endpoint registers, within the endpoint 
register file 198, are used to count packets, address data io 
storage locations within the dual port RAM device 214, and 
generally support the creation, reception, and error checking 
of data packets transferred to and from the USB host 128. In 
some cases, the endpoint register must be returned to the 
state that existed before the packet was sent, in order to 
support a "retry" on the part of the host. This will often 
require that the contents of the page and index pointer 
register 268 (shown in FIG. 7), the endpoint byte counter 
256 (shown in FIG. 7), and the SEQ bit 260 to be preserved. 
The following discussion details the general operational 
procedure for supporting such retries. 

Recall that each endpoint register 259 within the endpoint 
register file 198 consists of four bytes containing several 
fields, two of which comprises the page and index pointer 
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268, as shown in FIG. 7. Specifically, the low byte of the 
page and index pointer register 268 contains an index into a 
page, and generally points to the "next" location in dual port 
RAM device 214 from which a byte will be read or to which 
a received data byte will be written. In order to be able to 
retry a specific transfer, it is often necessary to temporarily 
save the index portion of the contents of the register 268, the 
SEQ bit 260; and the packet counter 258. In an embodiment 
of the present invention, the index is saved in the virtual 
endpoint register where it may be reloaded if a retry 
becomes necessary. The saved virtual endpoint register 
index is updated only if the transfer is successful. The same 
general approach is applied to the SEQ bit, and the packet 
counter Both of these states are maintained in the endpoint 
register 259. The update of these fields is delayed until an 
ACK is received from the USB host, or until all checks are 
completed on incoming packets. If the packet transfer fails, 
the updates are inhibited. When the outcome of the packet 
transfer is delected as being successful, (he SEQ bit is 
toggled, the packet counter 258 is decremented, and the 
index is copied to the index portion of the page and index 
pointer register 268 within the virtual endpoint register file 
storage location 248. 
Segmentation for Protection 

The page-based endpoint register feature of the USB 
RAM device 130 provides for primary protection and iso- 
lation of one endpoint from another and generally partition- 
ing these endpoinis such that a stall or problem on one 
endpoint typically prevents affects on other endpoinis. 
USB-RAM "Auto NAJC* Capability 

The receipt of a token for a specific endpoint always 
initiates a new transaction, and causes the virtual endpoint 
register in the virtual endpoint register file storage location 
248 that is associated with the specific endpoint to be 
partially loaded into the corresponding endpoint register file 
198 thereby pre-conftguring the USB RAM device 130 for 
the transaction. Some transactions are periodic, or in some 
way predictable, and the pre-configured endpoint registers 
generally are capable of immediate service in these cases. 
For example, the ISO IK registers (shown in the third row, 
or row '2% of the endpoint register file 198) can be preset to 
point to the data buffer 254 that In FIG. 5 will periodically 
be sent to the USB host. Some transactions are a periodic 
and asynchronous, and cannot generally be anticipated, an 
example of such types of transactions are SETUP transac- 
tions on the CONTROL pipe that issue standard request 
packets to the microcontroller device 140. In most cases the 
microcontroller device 140 cannot retrieve the request and 
setup the response thereto in the allowed response time. 
Therefore, the USB RAM device 130 initiates "auto-NAK" 
transactions. That is, when the microcontroller device is not 
prepared to respond to a request from the host, the USB 
RAM device upon detection thereof, automatically responds 
to the host with a "NAK" token thereby informing the host 
that the microcomputer is not ready, which implies that the 
host must try again Later. "NAK" tokens are repeatedly and 
indefinitely sent to the host by the USB RAM device until 
such time as when the microcomputer device generates an 
actual response to the host and signals the USB RAM device 
that the response is ready. In the preferred implementation 
this signaling is via interrupt from the microcontroller 
device. 

On an INTERRUPT pipe, the USB RAM device sees an 
"IN" token every frame or latency period. If the INTER- 
RUPT endpoint is not enabled, the USB RAM device issues 
NAK to indicate that it is busy. 

If the microcontroller device has command/event 
(incoming call, connect, disc, etc.), then the microcontroller 



device issues DATAO on ibe interrupt pipe in response to 
"IN" command. The host issues an "ACK" if "DATAO" was 
sent error free and if an error had occurred, no response is 
sent. 

Let's examine the microcontroller device procedure asso- 
ciated with the SETUP Descriptor Request operation: The 
USB RAM device recognizes toe SETUP Packet ID, checks 
the address, tbe endpoint and the CRC. If these are correct 
the SETUP is recorded as the "last" packet and the EOF is 
checked. Tbe host then sends an 8 byte long DAIAO packet 
containing a standard request for a descriptor. The USB 
RAM device sees the CONTROL endpoint and the "last- 
SETUP" and tests whether the CONTROL register has been 
enabled. The USB RAM device enables the (de-stuffed) 
incoming data buffer onto the internal data bus 168; then 
uses the CONTROL address and generates a write strobe to 
the USB RAM device, increments tbe index, decrements a 
byte counter and loops until the byte counter reaches zero or 
an EOP (end-of-packet) is seen, CRC- 16 is checked for 
validity and if valid, tbe USB RAM device writes ACK into 
tbe serial transmit subsystem 156 in FIG. 5, and also sends 
the microcontroller device a SETUP interrupt by writing into 
142 in FIG. 5. 

Default Map of Dual Port RAM for Microcontroller Appli- 
cation 

At this point, it suffices to briefly discuss the organization 
of data within the dual port RAM device 2 14. Referring now 
to FIG. 9, a memory map 300, which is the default memory 
map (or organization) of information stored in the dual port 
RAM device 214. It should be noted that the default memory 
map 300 is designed to support the Cyl23 ISDN Controller 
device, disclosed in U.S. PaL No. 5,541,93a 

The request storage location 142, for storing requests 
received from the USB host, is accessed by the address value 
0x7FF. When location 142 is written to, an interrupt is 
geoerated to the microcontroller device 140 through the 
"INT 1 line of the microcontroller lines 216 (shown in FIG. 
5). 

Tbe command storage location 144, for storing com- 
40 mands received from the microcontroller device 140, is 
accessed by tbe address value '0x7FE\ When written to, an 
interrupt is generated on the 'INT line of tbe bus 218 to the 
circuit 174. 

The mailbox storage location is used for storing pointers 
and comprises of three storage locations within the dual port 
RAM device 214, each of which is: a mailbox high storage 
location 301, by '0x7FC' for storing the 8 most significant 
bits (or MSB byte) of the mailbox information; a mailbox 
medium storage location 302, addressed by the value 
*0x7FB\ for storing the 8 middle bits of the mailbox 
information; and a mailbox low storage location 304, 
addressed by the value '0x7FA\ for storing the 8 least 
significant bits of the mailbox information. 

An interrupt address space 306 is assigned for storing 
interrupt packets starling at address '0x700'. The virtual 
endpoint register file storage location 248 starts at address 
location '0x780* and the SETUP storage location 250 starts 
at address location * 0x740'. 

Tbe USB RAM device is designed to allow default 
operation with minimal intervention by tbe microcontroller 
device. Most applications will probably be able to live with 
the default memory map 300, but can always over-write any 
endpoint register as appropriate. Any USB-RAM memory 
NOT defined for USB transfers is available for use by tbe 
application device, that is, the microcontroller 140. 

All Bulk operations are page-based and wrap around tbe 
page. The microcontroller device is interrupted when valid 



10 



15 



20 



25 



20 



35 



45 



50 



55 



60 



65 



07/31/2003, EAST Version: 1.04.0000 



US 6,219,736 Bl 



19 



20 



data is received or transmitted, and is responsible to prevent 
overruns or undemms. The microcontroller device can issue 
NAK's if necessary to throttle the USB host. 
Bulk-IN 

Referring now to FIG. 10, a Bulk endpoint register 
storage location 310 is shown included within the endpoint 
register file 198. The Bulk endpoint register storage location 
310 includes a Bulk page register 312 and a bulk index 
register 314, and a byte count field 316. 

When a Bulk <IN> token is received, a Bulk SEQ bit 320 
is tested, and DATAO or DATA1 is sent to the host, followed 
by ByteCnt bytes of data from the Bulk buffer, defined and 
accessed via the Bulk-ptr consisting of the address in 312 
and 314. 

If the data is received by the host with no error, the host 
sends an ACK to the device 130. When the device sees the 
ACK, it will toggle the SEQ bit 320, and store a Bulk index 
field 314 in the corresponding register 318 within the virtual 
endpoint register storage subsystem 248, indicating the 
location of the next BULK data byte to send in response to 
the next <IN>. If no ACK is received, the host detected an 
error, so the SEQ bit 320 is untouched, and the virtual Bulk 
index is read and copied into the Bulk endpoint register 310, 
pointing just past the last acknowledged good data in the 
Bulk buffer. Successful transfers cause the microcontroller 
device 140 to be interrupted. The microcontroller device will 
then use the index field 318 to determine how much data has 
been sent, to prevent overrun. The USB RAM device 
responds to <IN> tokens until the Bulk packet counter 258 
(FIG. 6) counts down to zero. 
Bulk-OUT 

Referring now to FIG. 11, a Bulk-Out endpoint register 
storage location 326 is shown included within the endpoint 
register file 198. When a good Bulk data packet is received 
by the USB RAM device from the host, the index is saved 
in the virtual Bulk-Out index field 322 of the virtual end- 
point register file storage location 248. The SEQ bit 324 
pertaining to the Bulk-Out endpoint register of the endpoint 
register file 198 is toggled, and an ACK is sent to the host 



reads 64-byte packet of data from locations 0x7C0 to 0x7FF 
within the dual port RAM and sends it to the host A default 
packet count 330 is one, but the microcontroller device can 
select larger packet counts if appropriate. 

In FIG. 12, the byte count 328 and the default packet 
count 330 are stored in an interrupt register 332 within the 
endpoint register file J 98, which also includes a page pointer 
334 having the value 4 7' and an index pointer 336 having a 
value that is within the range of the addresses assigned for 
storing interrupt information in the dual port RAM device, 
i.e. CO-FF Qn hexadecimal notation). 
ISO-IN 

Referring now to FIG. 13, the value of the default ISO-IN 
endpoint register 350 of the endpoint register file 198, is 
configured to point to the beginning of a 256-byte page, as 
shown in FIG. 13 at 352 (a page of storage location is shown 
at 354) and the bandwidth constraints are optimized by 
choosing four packets of 64 bytes each. This will cause the 
page to be sent in 4 milliseconds, while in ISDN 
applications, bandwidths cause a page to be filled every 16 
msec. Thus, the B -channel (used in ISDN applications) 
double buffers will be filled in 16 msec and drained in 4 
msec The microcontroller device must swap pages within 
the dual port RAM 214 before issuing the next ISO-IN- 
buf_ready command to USB RAM device. 

ISO-IN packets are always DA3A0 and are unacknowl- 
edged. No retries occur in isochronous pipes. If the packets 
have been transmitted, the USB RAM device will issue a 
'NAK' for each ISO-IN <IN> token. The next microcon- 
troller device ISO-IN command to the USB RAM device 
30 will cause the ISO-IN endpoint register to be reloaded, and 
the endpoint will be re-enabled by setting the enable bit 364 
of FIG. 7. It should be noted that isochronous pipes never 
STALL (since there is no handshake). 
ISO-OUT 

In FIG. 14, the default ISO-OUT end point register 356 is 
shown as being configured to point to the beginning of a 256 
byte out-page 358 in the dual port RAM 214. This is to be 
part of a double buffered pair of pages. By default, the 256 
page will receive four 64 byte packets in four milliseconds. 
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Optionally, the microcontroller device is interrupted. If bad 40 This is controlled by the client software on the host side, 



data is received from the host, the Bulk-Out index field in 
326 is loaded from the virtual endpoint register rile storage 
location 322, that is, the next location past the last good data 
is recovered, no ACK is sent to the host, and the SEQ bit 324 
is untouched. The host will detect the lack of an ACK and 
will retry the OUT Data transaction. The DATA0/1 sequence 
is bandied by the host. DATAO is chosen when the Bulk pipe 
is configured and the Bulk endpoint register storage location 
326 is loaded. If the Bulk pipe is stalled, both the USB host 
and the USB RAM device should reset to DATAO when 
STALL is cleared. Bulk transactions are re-tried if errors are 
detected. Successful transfers cause the microcontroller 
device to be interrupted. The microcontroller device will use 
the virtual index field 322 index to determine how much data 
has been received. 
Interrupt I/O 

As shown in FIG. 12, the value in the default INTER- 
RUPT endpoint register 332 of the endpoint register file 198 
is stored in and accessed from the interrupt address space 
306, at a location addressed by the value '0x7C0', within the 
dual port RAM 214. A maximum packet size, in terms of 
bytes, of 64, is assigned to the this endpoint, as indicated by 
byte count 328. If the INTERRUPT endpoint is disabled, the 
USB RAM device will respond to all Interrupt <IN> tokens 
with 'NAK'. The default interrupt latency is 1 millisecond. 
When INTERRUPT is enabled (by the microcontroller 
device), the USB RAM issues a DAIA0 to the host and men 
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Typically, the ISO-OUT transfers will be initiated by an IRP 
"Interrupt Request Packet" from the client, in response to an 
interrupt from the device. For ISDN B -channel data, this 
assumes approximately one msec for the < buffer_rdy' 
interrupt, and four msec to fill the buffer. Since buffers are 
swapped every 16 msec, this 5 msec transaction is OK, that 
is, the Data__Out_buffer will be filled in 5 msec, while it 
takes 16 msec to drain. 

ISO-OUT packets are always DA3X0 and are unacknowl- 
edged It is assumed that Ibe client software IRP's will issue 
the coned commands to the host software such that only 
four 64 byte packets will be sent per B -channel interrupt. 
Control 

Control transfers are intended to support configuration/ 
55 command/status type bidirectional communications 
between the client software and the device. As shown in 
FIG. 15, control transfers consist of a SETUP packet 360 
from the USB host 128 to the USB RAM device 130, 
followed by either no data transactions or one or more data 
60 transactions 361 in the setup specified direction, and a 
STATUS packet 362, which is transferred from the USB 
RAM device 130 to the USB host 128: the SETUP packet is 
8 bytes long and has a USB-specified structure. Data trans- 
actions following SETUP have no USB-defined structure, 
65 but will usually have a user-defined structure. 

The status transaction returns "success" when the end- 
point has completed processing the requested operation. The 



07/31/2003, EAST Version: 1.04.0000 



US 6,219,736 Bl 
21 22 

host can advance to the next CONTROL transfer after status Discussion of the Generic Commands 

is returned. The only USB defined "default" pipe is a Generic commands are coded as 0x3X (Le. *0\..*9\ V, 

CONTROL pipe with endpoint 0. TTiis is the pipe used to 4 ;' t '<% * m \ '>% *?') and are generally application and 

configure the system. Additional CONTROL pipes can be configuration independent The ASCII decimal digit com* 

defined. CONTROL pipes offer "best effort" delivery. CON- 5 mauds specify the endpoini register to be loaded from tbe 

TROL pipes can have a maximum packet size of 8, 16, 32, y^al endpoini register file 248, for example, command '2' 

or 64 bytes. The maximum packet size is always used for signals USB RAM device to load endpoini register #2 from 

data payloads. #2 in the virtual endpoini register file, where the default 

USB RAM Device Auto-NAK's on OUT Transfer control pipe is always endpoint register #0. 

Note thai the host can transmit any number of <OUT> 1Q ... (0x3D ) ^vises the USB RAM device thai the 

DATA transfers. This represents a potent^ I probkm i sin ce ^ address is available, and should be 

these data transfers may arrive at the USB RAM device ^ RAM device 214 into the address 

faster than the microcontroller device can handle them. After ^ " , 1 >nc 

the first <OUT> has been transmitted by the host, the J? 1 ** l0 " . f c t . ™ B DAM , . t . , a 

microcoatroller device can NAK the host, iereby prevent- ^?° d ' : ***** ^ ^^^p^ • 

ing following data transfers from occurring immediately. * SETUP packet has been received, and the USB RAM device 

That is. <OUT> packets are not processed and responded to load the control endpoint register with the default 

by the USB RAM device sending 'NAK' unless the endpoint index 0x40 and set the CONTROL_enable bit, that is, the 

is enabled. In this way, the microcoatroller device can reset Enable bit 264 (FIG. 7) of the control EndPt register, 

the CONTROL pointer to an alternative location. Note that Discussion of Pass Through Commands 

although CONTROL packets also wrap around a page, the 20 All other commands discussed above are to be passed 

default location for the CONTROL pointer is 0x740, and through the USB RAM device to the host, and through the 

wrapping around page 7 will typically lead to problems. host to the client (or user). Although the user software may 

Therefore, in the default case, the user software should limit be written to support other configurations, the recommended 

the amount of data sent to the device via CONTROL procedure for "pass-through" commands is as follows: 

packets, and/or the USB RAM device should throttle the 25 The microcontroller device (or application device) issues 

host via NAKs. The host will retry NAKcd transactions at a a command to the USB RAM device by writing to the 

later time. command storage location 144 (at address 0x7FE in the dual 

1. ) If a new SETUP is received before an old control port RAM device 214.) The USB RAM device 130 attempts 
transfer is completed, abort old transfer and handle new to interpret the command. If the command is a generic 
SETUP. 30 command, thee no assumption is made about the endpoini 

2. ) a stalled CONTROL endpoint should still accept configuration other than assuming that the default control 
SETUP PID. pipe is endpoint 0. If it is not a generic command code, or 
USB RAM Device Page-based Endpoints * ! then the USB RAM device assumes that it is a command 

All USB RAM device transfers are page-based. That is, code to be passed through to the host, and therefore an 

the USB RAM device includes memory that is divided into 35 INTERRUPT endpoint exists, and further that the INTER- 

8 pages of 256 bytes (0x100) each. When data transfer RUPT endpoint is endpoint #1. 

reaches the last byte in a page, OxNFF, the pointer will The USB RAM device then copies the Virtual Endpoint 

'wrap' around to the first byte on the page, OxNOO, instead R eg #1 into Endpoint Register #1, and sets INTERRUPT-, 

of advancing to the first byte on the next page, Ox(N+l)00. enable. By default, Endpoint #1 is setup to send one 64-byte 

This limits the damage that errors on one endpoint can have « packet of data, the data to be read from the dual port RAM 

on other endpoints. device 214, at addresses 0x7CO . . . 0x7FF. After the 

USB RAM Device Commands INTERRUPT packet is sent, the USB RAM device clears 

There arc two classes of USB RAM device commands: tbc INTERRUPT _JBUSY stale by writing zero to 0x7FE. 

1. Generic commands The ISO _JN_enable is not used, but could be, in addition 

2. pass thru commands 45 to the PklCclr[lSO_N] 

List of USB RAM Device Commands A generic command loads all of the virtual endpoint 

Generic Commands: registers' information from the virtual endpoint register file 

'0' Load Endpoini Reg #0 (in endpoint register fik 198 from storage location 248 into corresponding register locations in 

Virtual Endpoint Reg. #0 (in virtual register file storage the endpoint register file 198, thus the corresponding SEQ 

location 248) and enable so bit must be current. Everywhere the SEQ bit is toggled, its 

• 1' Load Endpoint Reg #1 from Virtual Endpoint Reg #1 and image in the appropriate virtual endpoint register file storage 

enable location 248 must be updated. 

<2' Load Endpoint Reg #2 from Virtual Endpoint Reg #2 and The Enable and SEQ bils operate as follows. Generally, 

enable the USB RAM device will toggle the SEQ bit (and zipdate 

4 9' Load Endpoini Reg #9 from 'Virtual Endpoint Reg #9 and 55 its Virtual image) while the microcontroller device sets the 

enable EndpoinUenable bit and the USB RAM device resets it. 

set the ControLjeoable and load ControLJndex Example 8051 (microcontroller device 140) response to 

V reserved CONTROL SETUP command from the USB RAM Device: 

reserved Upon tbe detection of an interrupt from the USB RAM 

copy host assigned address into device address register 60 device, the 8051 (the 8051 is a commercially available 

reserved microcontroller device from Intel and it is used as an 

# 7' dump Endpoint Reg file to dpRAM using pointer at example of the microoontroiler device) reads the command 

0x7FA,0x7FB storage location 142 (at address location 0x7FF in the dual 

Pass Thru Commands: port RAM device 214) and retrieves tbe 'SETUP' code, 

'all other codes' setup INTERRUPT endpoint register in 65 which informs the 8051 that tbe 8-byte SETUP data has been 

virtual EndPt register file 248, (FIG. 5) and set Interrupt^ stored in locations 0x740 . . . 0x747 of the dual port RAM 

enable bil of this EndPt register. device 214. The 8051 then interprets this data and deter- 
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mines that the standard request packet is a Set_Address reference, as are time multiplexed pipes. In FIG, 17, the 

command from the USB host. The 8051 will then command layered architecture of ISDN is shown, through a doited line 

the USB RAM device by writing to the command storage at 410, to extend through the layered architecture of USB, 

location 144 of the dual port RAM device 214, at location Additionally, a mapping is shown at 412 between ISDN" time 

OxTFE. The USB RAM device reads the command storage 5 multiplexed 'channels' 414 and USB time multiplexed 

location 144, determines whether it is the 'Address-'- 'pipes' 416. The 'channels' 414 form the communication 

command, reads the contents of the location 0x744 onto its Jink 408 (shown in FIG. 16) and comprise of a Bl channel 

internal data bus and writes this address into its address 4tg, a B2 channel 420, a D channel 422 and an EOC7M 

storage location 146. All incoming tokens with this address channel 424. Each of these channel is described in greater 

will now be recognized by the USB RAM device. Prior to 10 dctaii in ^ above-referenced and mcorporaled patent appli- 

this, only the default CONTROL 0 pipe was recognized. cllioiL ^ <pipcs » 416 arc ^ described above with reference 

If the standard request packet is any other Set_jrxx preocding Fia 16 . 

command, then the ^application device is assumed to know £h Q \ n ^ (or ^ 424 is shown to be commu- 

what to do with the command. Similarly, any Get^cxx ' ^ ^ g u of 

request packet from the host must be mterpreted by the ^ Tjsg faost: a faction laycr42<5; folWed by USB device 

application microcontroller device, and the appropriate data 15 , j7 , . c 1 . «u_ 1 tot 

St back to the host, transparent to the USB R/M device. layer 42S; Mow* by a USB bus mlerfacc layc^lo the USB 

More specifically, if ^standard request packet is any RAM. "0 through the USB interface 400 

Gel_xxxiequest, the application device should setup the This cornmimicaUon extends through the USB RAM 

desired information at an appropriate location (by default, device 130 by going through similar layers in the order 

starting at the CONTROL base, 0x740... 0x780) and then 20 shown by the dotted line 410 and thereafter continues, 

command the USB RAM device by writing the Setup code, through the ISDN interface 406, to the ISDN communica- 

V, into the command storage location 144, This assumes tion link 408 layers: a physical layer 432; a data link layer 

that the USB RAM device has been NAK'ing the <IN> 434; and a network layer 436. 

tokens from the host, since the CONTROL-enable bit is As described in greater detail in the above-referenced and 
assumed reset. The «:* command is read by the USB RAM 25 incorporated patent document, an interrupting dual port 
device and causes the USB RAM device to load the CON- RAM provides a powerful interface element capable of 
TROL endpoint register with the default CONTROL base supporting both MESSAGE and STREAM commiinica- 
(0x740), enable the endpoint, and respond to the next <IN> tions. The ISDN D channel 422 is MESSAGE-based, while 
token by sending a Datal packet using the CONTROL the Bl and B2 channels are primarily STREAM-based. The 
register parameters. 30 USB CONTROL pipe, within the pipes 416, is primarily 
When the 8051 (microcontroller device) sees the 'setup' MESSAGE-based while the ISOCHRONOUS and BULK 
command from the USB RAM device, it will read the pipes, within the pipes 4115, are STREAM-based. Therefore, 
request packet from locations 0x740 to 0x747. If the host in principle, it should be possible to map MESSAGE-based 
sends more data as <OUT> packets, the USB RAM device ISDN communications into MESSAGE-based USB, and 
writes the data starting at the CONTROL base at location 35 similarly, STREAM based ISDN into STREAM based USB, 
0x740. If, instead, data is requested from the 8051, the 8051 and vice versa and the present invention effects such map- 
writes the data into USB RAM device, starting, at the pings in a flexible general purpose architecture subject to the 
CONTROL, base, and issues the command to the USB previously discussed constraints of non-DMA type micro- 
RAM device. The USB RAM device will respond to the next computers. 

<IN> token on the CONTROL pipe by sending a Datal 40 The MESSAGE mode is the only bi-directional mode 

packet If the 8051 sees a vendor specific request packet, available. Messages transfer using a CONTROL pipe, 

with no following data required, then the microcontroller STREAM mode is for urn-directional DATA transfers, and 

device should respond with a zero-length Datal packet for ipplies to the INTERRUPT, ISOCHRONOUS, and BULK 

the Status stage of the setup. pipes. Thus, the host may issue Layer 3 ISDN commands 
USB-to-ISDN Layered Architecture and Time-Multiplexed 45 over a CONTROL pipe, while B-channel data may flow over 

Pipcs ISOCHRONOUS pipes. 

To this point, a general purpose USB-to-mkrocontroller Although the present invention has been described in 

interface has been described. Hereinafter, an optimal solu- terms of specific embodiments it is anticipated that alter- 

tion is presented for interfacing the USB host to the world- & tions and modifications thereof wfll no doubt become 
wide Integrated Services Devices Network (ISDN) network 50 apparent to those skilled in the art. It is therefore intended 

through an ISDN adapter. In FIG. 16, a high level diagram that the following claims be interpreted as covering all such 

is shown to include two major interfaces: a USB interface alterations and rnodification as fall within the true spirit and 

400 for interlacing an electronic communication device such scope of the invention, 

as a PC 402 to an ISDN adapter 404; and an ISDN interface What I claim is: 

406 for interfering the adapter device 404 through an ISDN 55 1. A RAM-based interrupl-driven interface device for 
communication link 408 to various types of communications establishing a communication link between a high perfor- 
devices (not shown). In an example embodiment of the mance serial bus host and a microcontroller device for 
present invention, the ISDN adaptor 404 may be imple- providing & control function, the interface being operative to 
mented as the USB RAM device 130, and a Cybernetic receive digital information in the form of command, data 
Micro Systems, Inc. CY123 device. Furthermore, the PC 60 and control packets from the host and to process the packets 
402 is an example embodiment of the USB host 128. and comnitinicate the processed digital information to the 
Because both USB and ISDN are layered architectures, and microcontroller device, and in response thereto, the micro- 
be cause both use time-multiplexed communication controller device being operative to communicate digital 
channels, the actual interfaces involved are shown in FIG. information to the interface device for processing and trans- 
27, 65 for to the host, comprising; 

Layered architecture is discussed in U.S. Pat. No. 5,541, means for receiving through said serial bus, a command 

930, the disclosure of which is incorporated herein by generated by the host; 
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